V predchádzajúcom článku sme sa venovali dôvodom, prečo je Test-Driven Development (ďalej len TDD) lepší ako programovanie testov až po produkčnom kóde. Ten článok bol zameraný na výhody pre produkt a firmu.
Je čas pozrieť sa na to, ako TDD môže pomôcť mne ako programátorovi. Takže dnes sa pozrieme na psychologické výhody TDD:
Po každom cykle vieme, že sme sa posunuli ďalej
Vývoj s použitím TDD je iteratívny. Po ukončení každého krátkeho cyklu vieme, že sme sa posunuli dopredu. A to vo viacerých aspektoch:
- Sme bližšie k hotovému riešeniu.
- Dizajn API je viac rozvinutý.
- Suita testov je kompletnejšia.
- Naše porozumenie riešeného problému rastie.
- Naša dôvera v komponent rastie s tým ako rastie jeho funkcionalita.
Rýchla spätná väzba, či robíme správnu vec
Každý cyklus trvá len pár minút a tak dlho trvá kým dostaneme spätnú väzbu o poslednom kroku.
Dozvieme sa napríklad toto:
- Ak nám vrámci posledného kroku začalo zlyhávať viac testov, môžeme sa zamyslieť nad dôvodmi. Môžeme si uvedomiť, že riešeniu celkom dobre nerozumieme, alebo sme sa v poslednom kroku snažili o príliš veľký prírastok kódu.
- Či sa navrhované API uberá správnym smerom. Ak sme museli prerobiť API dokončené v predchádzajúcich krokoch, je to signál, že treba spomaliť a premyslieť si či rozumieme špecifikácii, či je kompletná alebo či nám nechýba nejaká ďalšia informácia.
- Ak nevieme testu vymyslieť dostatočne dobré meno (gramaticky správna veta), je možné, že očakávaná funkcionalita nepatrí do tohto komponentu, ale do niektorého vstupného parametra.
- Ak je test príliš komplikovaný, môžeme sa zamyslieť, či sa nesnažíme testovať príliš veľa v jednom kroku, alebo či by sa komponent nemal rozdeliť na menšie časti testované nezávisle od seba.
- Ak cyklus trval príliš dlho, tak sa môžeme zamyslieť, či robíme dostatočne malé kroky, prípadne či naozaj rozumieme riešenému problému alebo použitým technológiám.
Vieme odhadnúť kedy budeme hotoví
Prerábky existujúceho kódu sú pri TDD menej časté. Nemyslím povinný refaktoring, ale zmeny názoru ako problém riešiť. Postup je tu zvyčajne lineárny, a teda vieme odhadnúť kedy sa dostaneme do cieľa.
Debugger je zriedkavo potrebný
Kvalitné a úzko zamerané testy sú mnohokrát dobrý ukazovateľ prečo test zlyhal. Keď k tomu pridáme aktuálny kontext — tých pár riadkov, ktoré boli zmenená od posledného úspešného spustenia testov, tak je pravdepodobné, že okamžite pochopíte kde je problém. Ak aj debugger spustíte, k oprave dospejete skôr.
Pozornosť venujeme len jednej veci
Keď píšeme test, sústredíme sa na to, aby bol jasný a čitateľný. K tomu patrí rozmýšľanie o API, vstupných údajov a verifikácii výsledkov. Potom sa zase venujeme tomu, ako zabezpečiť aby produkčný kód spĺňal túto novú špecifikáciu.
Takže naša pozornosť je zameraná buď na porozumenie a zápis toho, čo chceme dosiahnuť, alebo na to ako to dosiahnuť v implementácii komponentu. Čím menej detailov potrebujeme mať na mysli v danom okamihu, tým menej sú preťažené naše kognitívne schopnosti. Keď nie sú preťažené, tak budeme viac pozorní a menej unavení.
Priebežne dostávame nápady, aké testy nám ešte chýbajú
Keď pracujeme na riešení nejakého problému, dostávame nápady čomu sa ešte treba venovať. Majme napríklad test, ktorý posiela nejaké údaje do komponentu. Pri vývoji komponentu kladieme dôraz na to, aby sme ich správne použili. Ale všimneme si, že by sa patrilo otestovať neplatné hodnoty (napr. null). Nemusíme to spraviť hneď, lebo to nesúvisí s aktuálnym problémom a ani to žiaden existujúci test nevie odchytiť. Namiesto toho, aby sme odbočili od nášho problému si len spravíme poznámku, že treba pridať test na null a prenechať stratégiu spracovania chýb na neskorší test.
Dobré pocity
Asi vás nemusím presviedčať, že máme dobrý pocit, keď vidíme ako nám pod rukami vzniká fungujúci výsledok. Čo je menej jasné je, že dobré pocity nám umožňujú pracovať efektívnejšie a poskytujú vnútornú motiváciu.
Väčšia istota pri refaktoringu
Kvalitné testy s dobrým pokrytím nám odchytia viac prípadných problémov, ktoré vzniknú pri refaktoringu. Takže keď refaktorujeme a testy nezlyhávajú, znamená to len jedno. Nič sme nepokazili. Keby sme mali nekvalitné testy, tak to ešte môže znamenať, že testom sa problém nepodarilo zachytiť.
Záver
Nie každý má pri práci na pamäti dobro projektu alebo zamestnávateľa. Ale každému by malo záležať na sebe. A teda by sa mal snažiť nájsť spôsoby práce, ktoré mu vyhovujú a prinášajú dobrý pocit a spokojnosť. Test-Driven Development je dobrý kandidát na vyskúšanie, lebo benefity ktoré prináša sú rokmi overené.
Ďalšie Pavlove články na tému TDD: