Ruční testování nebo automatizace: co u aplikací odhalí víc

Dalším krokem je izolace testů. Každý test by měl být nezávislý a měl by mít vlastní simulované prostředí. Nepoužívejte sdílený stav mezi testy, jinak se výsledky mohou lišit podle pořadí spouštění. Pro vazby, které se mění v čase, použijte falešné hodiny nebo plánovač, abyste mohli simulovat plynutí času bez čekání. U asynchronních operací nahraďte skutečné čekání synchronním dokončením nebo použijte řízené sliby. Tím se vyhnete náhodným selháním a testy poběží výrazně rychleji.

Napiš pravidla, která platí pro všechny endpointy Největší čas se ztrácí na věcech, které nejsou v žádném konkrétním endpointu. Jak se předává autentizace, kdy vyprší token a co dělat při jeho expiraci, jak vypadá stránkování a řazení, jak se posílá datum a čas, jestli se čísla posílají jako řetězce, jak se zapisují peněžní částky. Tato pravidla patří do jednoho úvodu, na který se odkazuje zbytek dokumentace. Když je každý endpoint popisuje po svém, vznikají chyby, které se hledají celé hodiny, protože kód na první pohled vypadá správně.

Dokumentace REST API není popis toho, co všechno umí server. Je to pracovní nástroj pro člověka, který za týden nebo za měsíc usedne k frontendu a potřebuje vědět, co poslat a co dostane zpět. Pokud dokumentace vzniká až na konci vývoje, bývá neúplná a plná domněnek. Začni tím, že sepíšeš jeden jediný scénář: přihlášení uživatele, načtení seznamu položek, jejich úprava. Teprve z něj odvoď strukturu celé dokumentace. Většina týmů zjistí, že víc než polovinu endpointů lze popsat podle tří nebo čtyř opakujících se vzorů.

Propojení obou repozitářů řešte při nasazení, ne v kódu. Aplikace by měla konfiguraci načítat z předem dané cesty nebo z proměnných prostředí, nikoli odkazovat na konkrétní soubor v repozitáři s kódem. Názvy klíčů a strukturu formátu držte v obou repozitářích shodné, ideálně popsané jednou šablonou. Když se formát změní, upravte šablonu v repozitáři s kódem a hodnoty v repozitáři s konfigurací. Rozdíl odhalíte testem, který ověří, že všechny povinné klíče jsou přítomné.

Testování aplikací začíná u rozhodnutí, co vůbec ověřovat. Než napíšeš první test, sepiš si seznam rizik: co se stane, když aplikace spadne při přihlášení, když ztratí data, když pošle platbu dvakrát. Testy nemají pokrýt všechno, mají pokrýt to, co bolí nejvíc. Praktický postup je rozdělit aplikaci na vrstvy – datová logika, rozhraní, integrace – a pro každou zvolit jiný typ ověření. Bez tohoto rozdělení skončíš u hromady testů, které sice běží, ale nic nechrání.

Udržuj dokumentaci vedle kódu a aktualizuj ji ve stejném kroku, ve kterém měníš endpoint. Ideálně tak, aby se generovala z definice, kterou používá i server, a tím se nemohla rozejít s realitou. Ověřuj ji tím, že podle ní napíšeš testovací volání, a to spusť. Když příklad v dokumentaci nefunguje, je to chyba jako každá jiná. Zpětná vazba od frontendu je nejcennější zdroj: když se na něco ptá dvakrát, patří to do dokumentace, ne do chatu.

Nejčastější chyba je plošné nasazení jednoho limitu na celou aplikaci. Tím zpomalíte i běžné prohlížení a lidé začnou dostávat 429 i při normálním používání. Lepší je rozdělit trasy podle citlivosti. Veřejné čtení může mít vyšší limit, přihlašování a odesílání formulářů nižší. Do klíče, podle kterého se počítá, dejte kombinaci IP adresy a cesty, případně identifikátoru uživatele, pokud je přihlášený. Tím zabráníte tomu, aby jeden uživatel na sdílené IP blokoval ostatní.

Délka funkce je dalším spolehlivým indikátorem. Funkce nad dvacet řádků obvykle dělá víc věcí najednou. Rozdělte ji podle odpovědnosti: jedna funkce má mít jeden důvod ke změně. Když se v těle objeví víceúrovňové vnořené podmínky, použijte takzvané guard clauses — na začátku odchytte neplatné vstupy a vraťte se brzy. Vyhnete se tak zanořování, které se po pár úpravách změní v nečitelný blok.

U každého endpointu uveď čtyři věci: metodu a cestu, povinné a nepovinné parametry včetně typu a omezení, příklad požadavku a příklad odpovědi. Neopisuj jen úspěch. Uveď i chybové stavy, které frontend reálně potká: neplatný token, chybějící oprávnění, neexistující záznam, konflikt při souběžné úpravě. Ke každému přidej konkrétní stavový kód a tělo odpovědi. Pokud backend vrací chyby v různých formátech, frontend bude mít v kódu desítky podmínek, které se budou plést. Sjednoť tvar chyby ještě předtím, než začneš psát dokumentaci.

Používej reálné příklady, ne vymyšlené. Vygeneruj je z běžícího serveru a vlož tak, jak skutečně vypadají, včetně zanořených objektů a prázdných hodnot. Vyhni se popisům typu „vrací seznam" bez upřesnění, co je v položce a co znamená každé pole. U výčtových hodnot vypiš všechny možné varianty a napiš, co znamenají. Frontend pak nemusí hádat a backend nemusí vysvětlovat, proč se zobrazuje nula místo názvu stavu.