Chyby jsou povinnost

Zjistil jsem, že každý správný programátor by měl dělat chyby. Možná to může vyznít bláznivě, ale mám pro to své důvody, kterých je hned několik:

Asi jako nejdůležitější důvod je ten, abychom si udrželi práci. Představte si situaci, kde po vás zákazník chce nějakou aplikaci, kterou mu dodáte před termínem ve vynikajícím stavu (tzn. kde nejsou žádné chyby a odpovídá představám zákazníka). Myslíte, že vás bude zákazník po předání ještě potřebovat nebo že dostanete speciální odměnu? Ale kdepak… jen když v aplikaci budou chyby a nebude dle očekávání, máte možnost ze zákazníka dostat další prácí za feature, které nebyly v zadání.

S tím úzce souvisí další důvod – musíme si naši práci udržet, poněvadž přeci nic jiného dělat neumíme. Nebo dokážete si představit (pokud jste pravý noční tvor nazývající se developer) jak někde něco děláte rukama? Třeba zametáte chodníky? Přece takový člověk by si o koště přerail obě ruce.

Další neméně důležitý důvod je vzdělání. Přeci chybami se člověk učí. Nikdy se nenaučíte nic tak dobře jako tím, že něco zkusíte a ono vám to dá ránu, která vás naučí, že tohle se dělat nesmí. Třeba strkat vidličku do zásuvky. A čím víc chyb uděláme, tím víc špatných možností vyloučíme. Pak jednoho dne, až toho hodně vyzkoušíme, budeme vědět, která řešení jsou ta správná.

No a takový poslední důvod je abychom si připadali jako lidé a nikoliv jako stroje. Protože chybovat je lidské.

Tak, a teď vážně…

Zdůrazňuji, že potuď to byl žert!

Tento článek je o testování, konkrétně o tom, co vlastně testovat. Postupů pro to je několik a záleží, v jaké situaci právě aplikace je. Začnu od ideálního případu, kdy se teprve aplikace začíná vyvíjet.

SLIME

Zatím jsem neprozkoumal mnoho postupů, jak pokrývat aplikaci testy, ale osobně se mi prozatím nejvíce zamlouvá SLIME (by Adam Goucher), což je zkratka ze security, languages, requirements, measurement a existing.

Tedy nejprve otestovat bezpečnostní prvky. Například otestovat, že aplikace se ubrání proti různým útokům jako je napříkald XSS, CSRF, SQL injection, Clickjacking, zda se posílají hlavičky zvyšující bezpečnost a spoustu dalšího. Protože pokud aplikace bude mít problém s bezpečností, je většinou už jedno, že jinými chybami netrpí.

Další v pořadí je nutné otestovat, zda si aplikace poradí na všech místech s kódováním. Bylo by velmi nepříjemné narazit na skvělou aplikaci, kterou nemohu používat, protože místo písmenek vidím čtverečky kvůli špatnému kódování.

Dobrou technikou může být otestovat některé vlastnosti knihoven, na které je aplikace velmi závislá a není jisté, že autoři té knihovny nedostanou amok, kdy celé API změní bez předchozího upozornění. Poté může být velmi těžké zjišťovat, co se vlastně změnilo a co se musí upravit. Právě takovéhle testy by s tím měly pomoci.

Dále se hodí měřit výkon aplikace. Je to velmi podobné jako s jazyky – může se jednat o skvělou aplikaci, ale když budu čekat na odezvu příliš dlouho, velmi rychle mě to přestane bavit. Proto je dobré si napsat testy a nechat se upozornit, jakmile se výkon aplikace zhoršuje.

A nakonec testovat samotný kód, který vzniká. Jednotkové testy, integrační testy a tak dále.

80 % ve 20 %

Většinou se však snažíme testovat již existující aplikaci a tam už testovat předchozí body není úplně nutné, protože aplikace si prošla nějakým vývojem, kde se všechny popisované neduhy už (doufejme) opravily a testy by nepřinesly mnoho ovoce. Což ale neznamená, že to není užitečné – pokud se plánuje měnit jádro aplikace, určitě je užitečné si nejprve výše zmíněné testy napsat.

Popojďme ale dál k samotnému kódu aplikace. Určitě nejlepší strategie je začít těmi nejdůležitějšími a nejvíce používanými částmi aplikace. Existuje takové pravidlo 80/20, což znamená že 80 % všech chyb je 20 % kódu. Většinou toho nejvíce užívaného. Takže relativně během chvilky jsme schopni pokrýt spoustu věcí.

Mindmaps

Když už si myslíme, že jsme pokryli to nejdůležitější, chceme pokračovat dál a aplikace je tak rozsáhlá, že není lehké zjistit, co už pokryto je a co není, mohou pomoci mindmap grafy. Jedná se o diagram, ve kterém si postupně vyznačíme všechny funkčnosti aplikace.

Řekněme, že naše aplikace je e-shop. Začneme prvotní tečkou někde uprostřed a z té uděláme větve „uživatel“, „produkty“, „košík“, … Z košíku udvětvíme dál na „přidat do košíku“ a to můžeme zase odvětvit na „dynamické přidání pomocí JS“ a „klasické přidání“ atd. Pak zbývá jen fajfkovat, co už otestováno je a co nikoliv.

Nutno podotknout, že existují i utility, které prozkoumají pokrytí testů. Nemám s nimi ale dobrou zkušenost – čísla nejsou přesná a lze to využít jen pro jednotkové testy.

Dělat chyby

No a když už aplikace obsahuje spoustu testů a jejich psaní nás stále neomrzelo, zbývá poslední trik o kterém je tento článek – dělat chyby.

A dělat je záměrně. Nikoliv však kvůli důvodům ze začátku, ale kvůli otestování testů. Při úspěšném rozbití (jinak skvěle fungující, samozřejmě) aplikace lze jednoduše zjistit, kde mají testy mezery a je potřeba některé upravit či další připsat.

Tato poslední metoda neplatí jen pro případ, kdy už se neví, jaké testy napsat. Dobré je při psaní testu ověřit, že test funguje. Pokud se praktikuje TDD, tak se to vlastně dělá; ale pokud se testy dopisují k existujícímu kódu, je potřeba funkčnost testu ověřit dodatečně. Test, který je neustále zelený, je k ničemu…

Tak dělejme chyby!