Aplikace bez testování: Co všechno se může pokazit

Existuje jeden věčný dialog, který se odehrává v každé druhé softwarové firmě na světě. Projektový manažer řekne: "Nemáme čas na testy, musíme to dodat v pátek." A vývojář odpoví: "Dobře, ale..." — a to "ale" visí ve vzduchu jako předzvěst katastrofy.

My jsme za patnáct let viděli věci. Věci, po kterých se vám bude zdát, že automatizované testy jsou ta nejlepší investice, jakou můžete udělat. Pojďte se podívat na příběhy aplikací, které šly do světa bez řádného testování.

E-shop, který o víkendech rozdával slevy zadarmo

Jeden z našich klientů přišel s e-shopem, který vybudoval jiný tým. Všechno fungovalo perfektně — tedy od pondělí do pátku. O víkendu se ale začaly dít podivné věci: zákazníci platili za produkty výrazně méně, než měli.

Příčina? Časové zóny. Systém slev pracoval s UTC časem, ale kontrola "je slevová akce aktivní?" používala lokální čas serveru. Každý pátek ve 23:00 se aktivovala víkendová sleva, která měla platit až od soboty. A v neděli ve 23:00 se deaktivovala — o hodinu dříve, než měla.

Tohle není exotický edge case. Tohle je klasika. Ale nikdo to netestoval s různými časovými zónami, nikdo nenapsal test, který by ověřil přechod přes půlnoc. Výsledek? Tři měsíce nesprávných cen a ztráta v řádu statisíců korun, než si toho někdo všiml.

Poučení: Čas je v programování zákeřný nepřítel. Vždy testujte edge cases kolem půlnoci, přechodu letního/zimního času a různých časových zón.

Sociální síť, která sdílela víc, než měla

Tohle je příběh, ze kterého se nám dodnes ježí chlupy. Malá sociální aplikace, něco jako interní firemní chat. Funkce soukromých zpráv fungovala skvěle — dokud server nezačal mít výkonnostní problémy.

Vývojář přidal caching vrstvu. Zprávy se ukládaly do cache podle klíče, který bohužel nebyl dostatečně unikátní. Když dva uživatelé poslali zprávu ve stejnou sekundu, cache klíč kolidoval. Výsledek? Uživatel A viděl soukromou zprávu uživatele B.

Nikdo to neodhalil při vývoji, protože při ručním testování posílal zprávy vždy jeden člověk. Teprve když aplikaci začalo používat 200 lidí najednou, začaly chodit panické zprávy typu: "Proč vidím konverzaci Petra s HR o jeho výpovědi?"

Zátěžový test by tohle odhalil za pět minut. Ale zátěžové testy se nedělaly, protože "je to jen interní nástroj pro 50 lidí." Nakonec jich bylo 500.

Poučení: Soukromí uživatelů není něco, co můžete testovat "až bude čas." Cache invalidace je jeden z nejtěžších problémů v informatice — a zaslouží si vlastní sadu testů.

Bankovní aplikace, která kradla haléře

Příběh jako z filmu Office Space. Bankovní aplikace zaokrouhlovala transakce. Problém? Zaokrouhlovala vždy dolů. Každá transakce ztratila zlomek haléře, a ty zlomky šly... nikam. Prostě zmizely.

Na jedné transakci to bylo 0,004 Kč. Nic. Na milionu transakcí denně to bylo 4 000 Kč. Za měsíc 120 000 Kč. Za rok skoro půldruhého milionu. Peníze, které se prostě vypařily v zaokrouhlovací chybě.

Oprava byla triviální — správné bankovní zaokrouhlování (half-even, také známé jako "banker's rounding"). Jeden řádek kódu. Ale nikdo nenapsal test, který by sečetl tisíc transakcí a ověřil, že celková bilance sedí na haléř přesně.

Poučení: U finančních aplikací testujte aritmetiku obsesivně. Malé chyby se v měřítku mění v katastrofy. A nikdy nepoužívejte floating point pro peníze.

Formulář, který přijímal úplně všechno

"Validace? Na to máme čas až ve druhé fázi." Slavná poslední slova.

Registrační formulář jedné aplikace přijímal jako e-mail cokoliv, co obsahovalo zavináč. Takže asdf@ bylo platné. @@@ bylo platné. Dokonce i prázdný řetězec s jedním zavináčem @ prošel.

Ale to nebylo to nejhorší. Formulář také neošetřoval speciální znaky v uživatelských jménech. Takže se někdo zaregistroval jako <script>alert('hacked')</script> a každý, kdo navštívil jeho profil, viděl JavaScript alert. Klasický XSS útok, rok 2024.

A třešnička na dortu? Telefonní číslo akceptovalo písmena, takže v databázi byly záznamy jako "nevim", "zavolam pozdeji" a jeden kreativní uživatel zadal celou větu.

Poučení: Validace vstupů není "nice to have." Je to první linie obrany vaší aplikace. Každé pole formuláře je potenciální vstupní bod pro útočníka — nebo pro kreativního uživatele.

Proč se netestuje?

Důvody slyšíme pořád dokola:

• "Nemáme na to čas." — Ale čas na opravu produkčních bugů máte?
• "Je to jednoduchá aplikace." — Jednoduchá aplikace s jednoduchými bugy, které stojí reálné peníze.
• "Otestujeme to ručně." — Ručně otestujete happy path. Automatické testy otestují tisíc edge cases.
• "Testy zpomalují vývoj." — Ne. Bugy v produkci zpomalují vývoj. Testy ho v dlouhodobém horizontu zrychlují.

Co byste měli testovat minimálně

Nemusíte mít 100% pokrytí kódu testy. Ale určité věci byste měli testovat vždy:

1. Všechny finanční kalkulace — každý výpočet, který se týká peněz, musí mít testy.
2. Autentizaci a autorizaci — kdo vidí co, kdo může co.
3. Vstupní validace — co se stane, když uživatel zadá něco neočekávaného.
4. Edge cases s časem — půlnoc, přestupný rok, změna letního času, časové zóny.
5. Zátěžové scénáře — co se stane, když přijde 100x více uživatelů, než čekáte.

Testování není luxus, je to pojistka

Každý z výše uvedených příběhů měl jedno společné: oprava stála násobně víc než prevence. E-shop přišel o statisíce. Sociální síť ztratila důvěru uživatelů. Banka musela řešit audit.

Testování je jako pojištění auta. Platíte za něj a doufáte, že ho nikdy nebudete potřebovat. Ale když narazíte do stromu, jste sakra rádi, že ho máte.

Příště, až někdo řekne "na testy nemáme čas," vzpomeňte si na ten e-shop s víkendovými cenami. A pak si ten čas udělejte.