S automatizovaným testováním kódu (a ve zbytku článku budu mít na mysli právě to) jsem se setkal v několika firmách. Nikde ho nedělali. Když jsem se ptal proč, dozvěděl jsem se vždy nějakou variaci na starý příběh o testování.

Inu, v praxi je k ničemu každý pracovní postup, který aplikujete mechanicky, bez pochopení jeho podstaty (taková kargokultická metodika). Vzít si z agile jen „ranní porady“ je nejjistější způsob, jak zjistit, že „to nefunguje“.

Ruku na srdce – kolikrát se vám stalo, že jste o něčem prohlásili, že to je „naprosto na houby“, až vám jednoho dne někdo ukázal, jak to používat, a vy jste museli uznat, že nástroj je výborný a „na houby“ bylo hlavně to, že jste s ním neuměli nebo nechápali, k čemu je? Mně mockrát.

V pozadí mnohých sporů a odmítání je leckdy nepochopení. Dovolte mi, abych byl tedy chvíli „advokátem pro testování“; mým cílem není přesvědčit vás v článku o tom, že byste měli testovat a že se vám to vyplatí, ale zkusit vyviklat některé protiargumenty, v jejichž základu je právě nepochopení. Čímž neříkám, že můj pohled na testování je jediný správný (to ale nedělají ani advokáti; místo toho to nazývají „právní názor“).

Zvolený obor

Testování je velmi široká oblast a mnoha lidem splývá, proto než se pustím do obhajoby, musím nejprve vymezit oblast, které se bude obhajoba týkat. Rád bych se věnoval jednotkovým (unit) testům. Jsou pravděpodobně nejznámější, nejčastěji vyjmenovávané, ale na druhou stranu hodně specifické.

Jednotkové testy jsou automatizované postupy pro otestování jednotky kódu (třída, knihovna, unit, skript, … – tedy něco, co lze samostatně testovat). Jejich cílem je strojově otestovat, zda daná jednotka dělá to, co dělat má, a zda nedělá něco, co dělat nemá. Je jasné, že automaticky můžeme otestovat pouze to, co se automaticky otestovat dá, resp. co lze automaticky otestovat snadno.

U jednotek testujeme, zda:

1. vrací správné hodnoty na správné vstupní údaje
2. vrací správné hodnoty na mezní vstupní údaje
3. legitimně zhavaruje tehdy, když zhavarovat má

Co to znamená? U jednoduchých funkcí zadáváme vstupní hodnoty a kontrolujeme výstupní, resp. chování funkce. U složitějších testujeme to, co testovat lze. Kupříkladu u třídy, která bude generovat CAPTCHA obrázek, nebudeme psát OCR, který bude vyhodnocovat, zda výsledek opravdu obsahuje požadované znaky, to je extremistický nesmysl. Otestujeme, zda při zadání dobrých vstupních údajů vygeneruje třída obrázek, jestli ten obrázek má patřičné rozměry a patřičný formát. To je snadné otestovat. To, jestli obrázek obsahuje opravdu daný text daným fontem, už nebudeme řešit unit testem; ověříme to metodou „kouknu a vidím“.

Jednotkové testy by měly v ideálním případě otestovat každou metodu třídy, každou funkci v knihovně, každý řádek kódu, navíc takovým způsobem, který je nezávislý na zbytku systému či na vnitřních stavech. Každý „testovací případ“ by měl pracovat s čistou kopií jednotky.

Pokud jednotka používá nějaké komplexní funkce „zvenčí“, pak pro testování podstrčíme „mock object“, který se bude navenek tvářit tak, že opravdu funguje, ve skutečnosti ale jen vrátí testovací data. Řekněme, že budeme testovat HTML generátor, který generuje stránky ze záznamů v databázi. Namísto objektu, který přebírá data z databáze, podstrčíme „mock“ – jednoduchou třídu, která má stejné rozhraní, ale na getTextById() vrátí testovací „Lorem ipsum“. Jednotkové testy tak proběhnou nezávisle na okolí.

Jednotkovými testy netestujeme, zda jednotka funguje spolu s ostatními; od toho jsou integrační testy. Netestujeme jimi ani to, jestli celá aplikace funguje. Očekávat, že jednotka pro generování HTML funguje, a tím pádem musí fungovat celý web, je bláhové. V dalším textu se nebudeme zabývat ani integračními testy, ani testováním aplikace, zůstaneme jen u automatizovaných jednotkových tes­tů.

ISO9001

K čemu nám tedy takové testování je? Nezjistíme tím, jestli to spolupracuje se zbytkem aplikace, nezjistíme, jestli aplikace funguje… Automatizované unit testy mají jinou hodnotu: jsou automatické (můžou tedy běžet bez zásahu člověka, např. na serveru jako hook u verzovacího nástroje), opakovatelné a jejich výsledky lze dobře zpracovat.

Trochu to připomíná známou (a mnohými proklínanou) normu ISO9001. Tato norma nezajišťuje, jak si mnozí lidé myslí, jakost výrobků. Tato norma je zaměřena na to, aby veškeré procesy byly jasně popsané, specifikované a opakovatelné. ISO9001 vám nezaručí, že při výrobě neuděláte chybu. Postup podle této normy pouze zaručí, že chybu uděláte vždy stejně (pokud je procesní), nebo že zjistíte, kde vzniká, protože jednotlivé kroky jsou přesně popsané. Ano, je to opruz, popisovat přesně všechny procesy, sepisovat lejstra o tom, co se dělá a jak se to přesně dělá. Ale když je někde chyba, můžete se postupů popsaných v lejstrech při hledání držet. Buď zjistíte, že někdo postup nedodržel, nebo že je v procesu chyba – a pak ji můžete opravit a popsat proces znovu.

S testováním je to podobné. Test není vaše ověření, že vše funguje; na to by byl leckdy opravdu drahý. Test je nástroj pro dlouhodobou udržitelnost kódu a pro rozumnou práci s ním. Dobře napsané testy dokáží odhalit problémy při zásahu do kódu. Většinu situací „tady přepíšu pár řádků, bude to ale fungovat stejně“, které vedou k prapodivným chybám, můžete s jednotkovými testy zachytit dřív, než si zavlečete do kódu skryté chyby.

Test je tak dobrý, jako jeho autor

Testování je jako španělská hospoda – najdete tam jen to, co si s sebou přinesete. Žádný test neobjeví v kódu nic, co autor nedokáže popsat. Myslet si, že unit test objeví chybu tam, kde nikoho nenapadlo, že by mohla být, je naivní.

Napsat dobrý test je trošku umění, především proto, že mnozí lidé postupují při ověřování chybně. Lidský mozek má tendenci hledat případy, které naši teorii potvrzují, namísto toho, aby hledal případy, které by jí vyvracely, kdyby fungovaly. Jinými slovy: musíme testovat nejen správnou funkčnost, ale i správnou nefunkčnost. 

Najít ale všelijaké kombinace, které by měly zhavarovat, vyžaduje opravdu zkušeného programátora s dobrou fantazií. Taky nikdo netvrdí, že napsat dobré testy je hračka!

Jednotkové testování není všespásné

Myslet si, že napíšu jednotkový test a knihovna bude automaticky dobrá a použitelná je bláhové. Myslet si, že jednotkový test zaručí kvalitní kód, je taky nesmysl. Přesto mnozí očekávají od jednotkových testů něco, co jim jednotkové testy nemohou nabídnout, a jsou pak rozčarováni z toho, že jejich očekávání nebylo naplněno. Často pak z neúspěchu viní testování jako takové.

Zopakujme si ještě jednou: Jednotkové testy slouží k automatizovanému, opakovatelnému a strojově zpracovatelnému testování izolovaných funkcí. Není to nástroj pro zajištění kvality nebo vhodnosti pro daný účel; nenahradí to dobrou analýzu ani dobrý návrh. Použijete je hlavně při dlouhodobé údržbě vlastního kódu. Naprosto neocenitelné jsou jejich služby ve chvíli, kdy napíšete „verzi 2“, která „by měla být kompatibilní s verzí 1“. Máte-li „verzi 1“ pokrytou dobrými testy, uvidíte na první pohled, jak to s tou kompatibilitou ve skutečnosti je.

Pokud píšete kód vždy důsledně jen na jedno použití, nasadíte ho do aplikace a pak už se k němu nikdy nevrátíte, tak pravděpodobně tuhle výhodu neoceníte. Po pravdě řečeno v takovém případě máte hlavně úplně jiný problém než to, že netestujete…

K čemu tedy?

Pokud se držíte metodiky TDD, tedy že nejprve píšete testy a až po nich kód, tak můžete brát psaní testů jako první použití vašeho nového kódu. Berte to jako příležitost zjistit, jak se s ním pracuje, a to ještě dřív, než ho opravdu napíšete. Uvidíte svůj kód očima jeho uživatele, což je zkušenost k nezaplacení. Třeba zjistíte, že budete muset něco v API změnit či upravit…

TDD bývá někdy některými hodnocena jako příliš ortodoxní. Asi není třeba být vždy a za všech okolností doslovný a pokud napíšete nejdřív jednoduchou knihovnu a až po ní testy, nebude to jistě žádné velké neštěstí. Jen pozor na to, že při obráceném postupu má člověk stále ještě v hlavě vlastní kód a mnohdy píše testy „na míru svému kódu a svým chybám“.

Testy patří k bontonu!

Testy jsou v podobné roli jako dokumentace: programátoři mají odpor k vytváření, protože to je „neproduktivní práce“. Když člověk programuje, v hlavě mu letí myšlenky a na nějaké psaní dokumentace není čas… Maximálně tak nějaký ten komentář do kódu.

Propagátoři nových jazyků a čistého kódu hovoří o dokumentačních komentářích jako o samozřejmosti; měly by patřit do kódu stejně samozřejmě jako odsazování. Stejný pohled se začíná prosazovat i v oblasti testování. Pustit open source knihovnu do světa bez sady testů (a bez dokumentace) je v jistých kruzích už programátorské faux pas: k čemu mi je kód, který si můžu upravit, když nemůžu rychle zjistit, jestli mi úprava něco nerozbila?

Napsat dobrý test je nutnost, pokud chceme svým kódem přispět do většího projektu. I ve firmách, které nedělají open source, je často používáno automatické testování, ať už kvůli Continuous Integration, tak třeba i pro měření kvality práce programátorů – pokud někdo soustavně commituje změny, které neprojdou testem, lze to snadno dohledat a zjistit příčiny.

Testy, podobně jako dokumentace, nejsou v podstatě nikdy hotové a kompletní. To, že se v kódu objeví chyba, kterou test nezachytil, není důkaz toho, že jednotkové testování nemá smysl, ale toho, že byl test neúplný. Můžete se rozčílit na všechny propagátory testů a napsat jim to do diskusí, nebo můžete problém popsat testem; to druhé bývá rychlejší a smysluplnější. Stejně tak když vám kolega řekne, že mu vaše třída nefunguje za takových a takových podmínek: to je ideální příležitost ty podmínky nasimulovat v testu!

A nezapomeňte: dobrý test vám kryje záda, když jde do tuhého a hledá se viník!

Stejně ale…

Pro nás je to drahé a zdržuje to.

Zkusili jste si to, testy jste psali tak, jak se psát mají, všechno jste udělali správně, ale zdržovalo vás to. Knihovny totiž nikdy nepřepisujete a ty testy byste stejně spustili jen jednou. Pak asi ano, pokud jste si jisti, že jste všechno udělali správně, a přesto jste si spočítali, že se vám to nevyplatí, tak OK. 

Nám chyby v kódu nevadí.

Komu by vadily, že? Místo psaní testů vymyslíme, jak opravy kódu prodat zákazníkovi jako vícepráce, a vyděláme na tom!

Můj kód je vždy perfektní, protože jsem špičkový programátor.

Pardon, testem jsme vás nechtěli urazit. Víme, že jste špičkový stroj na kód, který není nikdy unavený, nikdy nedělá chyby, nikdy se nepřepíše, vždy je stoprocentně koncentrovaný – a že tomu věříte. Máte pro to ale i nějaký jiný důkaz než svoje tvrzení?

Všechny tyhlety takzvaný „metodiky“ jsou jen tlamocviky mladých frikulínů, které mají zakrýt, že vlastně vůbec neuměj‘ programovat…

Ale jistě… „Opravdový programátor“ napíše cyklus DO přes tisíc řádků, a nesplete se! Přidejme ještě „pravidla jsou pro slabochy“ a „čára není zeď“, ať to máme komplet. Ale upřímně – pokud si myslíte, že programování je umění, měli byste programy vystavovat na výstavách, a ne je cpát lidem do počítačů, aby s nima pracovali…

Shrnutí

• Testy nejsou kouzlo; je to metoda. Když ji neumíte a děláte ji špatně, nebude vám fungovat, tak prosté to je.
• Jednotkové testy testují to, co říkají: funkčnost jednotek kódu.
• Automatizovaný test otestuje jen to, co do něj napíšete.
• Jednotkový test nenahrazuje jiné metody testování; doplňuje je. Pokud chcete testovat, jak to bude fungovat dohromady, slouží k tomu integrační testy.
• Jednotkové testy děláme proto, že jsou opakovatelné, automatizovatelné a jejich výstup lze strojově vyhodnotit.
• Automatizovaný test nemá, na rozdíl od člověka, „své dny“ a vždy testuje vše tak jak má. Neznamená to ale, že můžou člověka plně nahradit – jen mu ulehčují mechanickou práci.
• Testování není ladění.
• Test je jen tak dobrý jako jeho autor; je-li autor lemrouch, je i test špatný.
• Hodina vynaložená na psaní testu ušetří den hledání podivné chyby za půl roku. Pokud hodláte ještě za půl roku pracovat ve stejném oboru, zvažte tento aspekt.

Ke čtení naleznete mnoho různých materiálů, od teoretických po praktické ukázky. V češtině mě zaujala velmi podrobná Příručka o testování (pdf) od Anny Borovcové (blog).