Návrh API a testování

Při návrhu API je potřeba stanovit kromě způsobu komunikace i časy do kterých má rozhraní reagovat. Při vývoje ji pak dobrý nápad zahrnout do testovacích scénářů i testy, které prověří rychlost API. Co je Vám platné když stihnete termín, vše v přádku nasadíte, ale první klient který použije program v praxi na svích 10.000 záznamů se výsledku dočká až druhý den?

Napište test který pomocí API založí záznam a zase ho načte. Co se stane když ho obalíte FORem a spustíte ho 10.000x ? Pomocí StopWatch si to můžete stopnout a pokud se čas přehoupne přes určitou mez tak test nechejte spadnout.

Fajným zabijákem výkonu je reflexe. Mega fajným zabijákem výkonu je reflexe v cyklu.

Určitě dobrý nápad je vyvýjet API a klientsou knihovnu v oddělených projektech od celého systému. Tím se Vám zjednoduší údržba a vývoj.
API na servrové straně a klientskou část můžete společně verzovat a společně nasazovat.
Navíc je můžete společně i testovat bez nutnosti nasazovat celý systém např UI vrstvu. Máte přece UI vrstvu zvlášť? Nebo ne?

Testování

můžete napsat test který načte z api záznam a zkontroluje jestli všechny atributy obsahují očekávané hodnoty. Co se Však ale stane pokud nasadíte novou verzi a databáze je prázdná? Test spadne.
Lepší variantou proto je vytvořit testovací netodu která založí pokaždé nový záznam a ten na serveru vyhledá a zase si ho stáhne a porovná odeslané a přijaté hodnoty mezi sebou. Otestujete jak vytvoření záznamu, tak jeho stažení a porovnáním hodnot mezi sebo zkontrolujete jestli to co odesíláte se vám vrátí.
Klasický případ je že odešlete DateTime včetně času, server ale časovou složku zahazuje a ukládá pouze datum. Nebo datum vrací v jiném formátu.

Každou entitu se kterou je možné prostřednictvím API pracovat by měli pokrýt minimálně 4 testy (CRUD). Víše zmíněný test pokrývá dvě ze čtyřech.