v kategorii Nic z následujícího textu není nové. Určitě to někdo v podobném znění už někde sepsal. Ale pořád se na to naráží a opakování je matka moudrosti. :-)
Extrémní TDD říká, že by se měl napsat minimální test, počkat až selže, poté napsat minimální kód pro průchod testu, ověřit funkčnost, rozšířit test a tak pokračovat do nekonečna. Například:
- Napíšu test na zavolání funkce add.
- Test selže, protože funkce add neexistuje.
- Napíšu funkci add. Jen definici, aby ji šlo zavolat.
- Test projde.
- Napíšu test, že funkce vrací pro parametry 2 a 3 hodnotu 5.
- Test selže, protože funkce nic nevrací.
- Napíšu return 5.
- Test projde.
- Napíšu test, že funkce vrací správné výsledky i pro jiné hodnoty.
- Test selže, protože vrací stále samé číslo.
- Napíšu algoritmus pro běžná čísla.
- Test projde.
- Napíšu test na mezní hodnoty.
- Test selže.
- …
Kvůli tomu často lidi na TDD zanevřou a buď testují špatně nebo vůbec. Aspoň mi to tak přijde. Přitom, pokud se to nevezme tak extrémně, je programování mnohem lepší. Mám totiž svoji verzi TDD: zůstávám u psaní testu předem, ale neiteruji tolik vášnivě. Testy spíš beru jako takový popis, co vlastně chci dělat. Dokumentaci, dá se říct. Ono pokud žádná dokumentace neexistuje, dá se právě z dobrých testů něco pořádného vyčíst. Můj styl je:
- Napíšu všechny testy, co mne na začátku napadnou, pro funkci add.
- Napíšu celou implementaci funkce add pod dozorem testů.
- Při psaní samotné funkce (či potom) dopíšu další testy, co mne při vývoji napadnou.
Nojo, jenže stále tam je ten test na začátku. Jak mám napsat test, pokud nevím co chci programovat? Otázka, kterou slýchám často. Na to snad jen, pokud nevím, co chci programovat, tak snad raději neprogramovat vůbec. :-)
Na test předem lze nahlížet jako na ukázku předem. Nejprve si tedy udělám kód jak chci asi danou funkci používat. Samozřejmě kód nebude funkční, jde jen o to podívat se, jak skutečně chci funkci využívat. Jakmile zjistím, jak chci funkci využívat, mohu začít psát implementaci. A pokud mám ukázku, upravit ji na test je už drobnost.
Tím si zároveň ušetříte práci. Udělat dobrý návrh na první dobrou vyjde málokdy. Proto je lepší se nejprve zamyslet nad použitím a podle toho udělat API. Jednodušší upravovat ukázku, než udělat celou implementaci a pak zjistit, že se to používá špatně a je třeba celé přepsat.
Dokážu si však představit situaci, kdy nejde napsat test dřív. Například při psaní Selenií. Nebo dělám prototyp čehokoliv a opravdu nemám představu, jaký výsledek bude, a nejde mi o to mít po celou dobu plně funkční kód (který z většiny stejně smažu). Pak je potřeba mít na paměti dvě věci:
- Test musím vidět selhat. Pokud napíšu test po kódu, musím kód naschvál rozbít, abych viděl, že test opravdu testuje. Nejde nijak jinak podchytit testy, co nic netestují, než ověřením, že opravdu selhávají. A že jsem už na takové narazil!
- Pokud programuji z nějakého důvodu bez testu, napíšu kód nejhloupěji, jak dovedu. Abych při pohledu viděl, že tam není chyba. Poté napíšu testy. Nakonec kód mohu zrefaktorovat a případně i zoptimalizovat. Nejvíce chyb totiž nastává při zhezčování kódu, refaktoringu či optimalizaci. Proto je dobré tuto fázi udělat až s testy.
To jest vše. Kolem testování se dá filosofovat nad více věcmi, ale tohle jsou nejpalčivější otázky, které dostávám a které jsem kdysi sám řešil. Snad jsem vám nějak pomohl. :-)
kanálu