Kdy testovat chybové stavy a hraniční hodnoty, aby vstupy nepadaly?

U časových závislostí – časová razítka, platnost tokenů, naplánované úlohy – nikdy nečtěte skutečný čas přímo. Zaveďte si jednoduché rozhraní pro zdroj času a v testech ho nahraďte pevnou hodnotou. Stejně tak náhodná čísla a identifikátory: pokud ověřujete konkrétní výstup, potřebujete deterministické hodnoty. Jinak testy občas projdou a občas ne, což je horší než jasná chyba.

Většina chyb v aplikacích nevzniká uprostřed běžného provozu, ale na okrajích — tam, kde vstup přestává být typický. Testování chybových stavů a hraničních hodnot znamená systematicky procházet místa, kde se data lámou: prázdný řetězec, nula, záporné číslo, maximální délka, neplatný formát. Cílem není vyzkoušet všechno, ale najít hranice, za kterými se chování mění.

Klíč, hlavičky a limity: co tě zastaví jako první Jakmile přejdeš od veřejných dat k ostrému API, narazíš na autentizaci. Nejčastěji jde o klíč v hlavičce požadavku, někdy v parametru adresy. Klíč nikdy nevkládej do veřejného kódu ani do repozitáře. Ulož si ho do proměnné prostředí a v kódu ho čti odtud. Druhá častá překážka je limit počtu požadavků za minutu. Překročíš ho a server vrátí chybu 429. Řešení je jednoduché: mezi voláními dělej pauzu a odpovědi ukládej do mezipaměti, dokud jsou platné.

Odhad není smlouva. Je to nástroj pro rozhodování. Když se změní zadání, musí se změnit i odhad. Když se objeví nová informace, je normální ho upravit. Tým, který se drží zastaralého čísla jen proto, že bylo řečeno nahlas, nakonec dodá něco jiného, než bylo potřeba. Zdravý přístup je odhadovat průběžně, mluvit o nejistotě otevřeně a mít rezervu na věci, které nikdo nečekal.

Kde se hraniční hodnoty nejčastěji podceňují U textových polí lidé zapomínají na prázdný řetězec a na řetězec složený jen z mezer. Obojí může projít validací, ale později shodit databázi nebo logiku. Dále testujte maximální povolenou délku a o jeden znak delší vstup — pokud aplikace ořezává potichu, ověřte, že to dělá správně. U čísel nezapomeňte na nulu, záporné hodnoty a desetinná místa tam, kde se čeká celé číslo. U data zkuste neplatný den v měsíci, přestupný rok a posun času.

Praktický postup je zavést takzvaný odhadovací rituál. Před plánováním sprintu dostane každý člen týmu stejný stručný popis analytického úkolu. Nejdřív ho ohodnotí samostatně, pak se sejde celý tým a rozdíly se vysvětlují. Nejde o to najít přesné číslo, ale odhalit rozdílné předpoklady. Pokud se odhady liší o dva a více stupňů, znamená to, že zadání není dost jasné, nebo že někdo vidí skrytou složitost. Výsledkem je buď doplnění informací, nebo rozdělení úkolu na menší části.

Pro první vlastní volání si vyber jednoduchý scénář: načti seznam položek, vypiš jejich názvy a počet. Nepřidávej filtrování ani stránkování, dokud základ nefunguje. Potom zkus jeden parametr navíc, třeba limit nebo vyhledávání. Sleduj, jak se změní odpověď. Tímto způsobem si osvojíš logiku dotazů rychleji než čtením desítek stránek dokumentace. Až budeš mít jistotu, přidej druhé volání, které použije data z prvního – například detail podle identifikátoru.

Začněte tím, že si pro každý vstupní parametr sepíšete, http://crativ.co.kr/bbs/board.php?bo_table=info1&wr_Id=140413 co vlastně přijímá. U čísla to je rozsah, u textu maximální délka a povolené znaky, u data formát a časové pásmo. Teprve pak volte hodnoty. Pro číselný rozsah testujte pět bodů: minimum, těsně pod minimem, střed, těsně pod maximem a maximum. Přesně na hranici často selže porovnání typu menší nebo větší a vznikne chyba o jedna.

Praktický postup: pro každý vstup napište tabulku hodnot, spusťte je a výsledek porovnejte s očekávaným. Neúspěch není jen pád, ale i tiché přijetí nesmyslu. Automatizujte opakované případy, ručně pak zkoumejte ty, kde se mění stav nebo kde vstup ovlivňuje jiné části systému.

Kdy je jednodušší stub než celá atra

Nakonec ověřte, že se chyby správně logují a že zprávy neprozrazují citlivé údaje. Hraniční testy mají smysl jen tehdy, když po nich následuje oprava a nový test, který potvrdí, že hranice drží i po změně kódu.

Největší chyby začátečníků nejsou v kódu, ale v předpokladech. Mnozí očekávají, že odpověď má vždy stejný tvar. Jenže API se mění, pole mohou chybět a hodnoty mohou být null. Vždy kontroluj stavový kód odpovědi, osvětlení v obýváku ne jen tělo. Když přijde 400, 401 nebo 404, tělo často obsahuje vysvětlující zprávu. Čti ji. A nikdy neposílej požadavek bez ošetření chyby – i jednoduchý pokus může spadnout na výpadku sítě.

API nezačíná registrací ani klíčem. Začíná tím, že si v prohlížeči otevřeš dokumentaci a najdeš jeden koncový bod, který vrací data bez přihlášení. Většina veřejných API má takzvaný health check nebo jednoduchý GET požadavek, třeba na výpis položek. Ten si zkopíruj do adresního řádku a stiskni Enter. Uvidíš surový JSON nebo XML. To je celé první setkání s API – žádná magie, jen text, kterému se dá naučit rozumět.

In case you loved this informative article and you wish to receive much more information with regards to byt V paneláku assure visit our own page.