Kedy nepoužívam TDD?

Predpokladám, že väčšine z vás napadlo, že vo vašom prípade, sa Test-Driven Development nedá použiť. Čiastočne máte pravdu. TDD, ako všetko ostatné na svete, má svoje výhody a nevýhody. Má svoje silné stránky a aj slabé. V tomto článku sa chcem venovať situáciam, kedy TDD nie je najvhodnejší nástroj.

Programujeme známy a netriviálny algoritmus

Máme za úlohu vytvoriť komponent na nájdenie najkratšej cesty v grafe. Napísať prvý test a vytvoriť riešenie pre 1 uzol je triviálne. Asi vieme pridať aj test pre 2 uzly. Ale potom sa to začína komplikovať. Nebýva jednoduché umožniť testom (vstupným údajom) riadiť vývoj algoritmu správnym smerom. A je dosť možné, že ani nemusíme rozumieť všetkým detailom ako ten algoritmus funguje.

V takejto situácii je podstatne jednoduchšie otvoriť knižku alebo Wikipediu a algoritmus jednoducho odpísať.

Prototypovanie

Keď je naším cieľom vytvoriť prototyp niečoho nového, je bežné, že nemáme predstavu ako to dosiahnuť. V podstate pracujeme štýlom pokus-omyl. Písať testy pred kódom má 2 problémy:

• nevieme čo do testu napísať, ak si to najskôr nevyskúšame
• pri hľadaní riešenia je dôležitejší čas, za aký sa k funkčnému prototypu dostaneme ako kvalita, ktorú dosiahneme. Inými slovami, písanie testov nás zdržuje a je možné že sa prototyp nakoniec zahodí¹.

Nepoznáme technológiu, ktorú musím použiť

Tento dôvod sa podobá na predchádzajúci. Najväčší rozdiel je asi v tom, že to nikto nenazýva prototyp alebo Proof of Concept. A očakáva sa produkčná kvalita. Moje odporúčanie je dodržiavať dobré dizajnové návyky, tak aby bol komponent testovateľný a dopísať testy dodatočne. Pre skúsených TDD-čkárov by to nemal byť problém. TDD ich naučilo, že triedy a metódy majú byť dostatočne malé a pospájané tak, aby sme ich vedeli testovať nezávisle od seba.

Potrebujeme dorobiť novú funkcionalitu do hnusného kódu s nečitateľnými testami

Nevieme ako testy fungujú a funkcionalita je niekde uprostred testovaného kódu. Tu je fakt ťažké napísať nový malý test a upraviť produkčný kód.

V lepšom prípade môžeme pridať novú metódu, ktorú otestujeme priamo novým testom. Ale keď novú metódu zaintegrujeme do existujúceho kódu, tak začnú zlyhávať niektoré staré testy. A keďže im nerozumieme , tak ich nie je ľahké opraviť.

Ak máme čas, môžeme sa pokúsiť zrefaktorovať testy a produkčný kód. A novú funkcionalitu implementovať až potom. Ale zvyčajne čas nie je. A sme opäť pri tom, že TDD nefunguje 😀.

Kompilácia alebo testy bežia príliš pomaly

Ak máme pomalé prostredie alebo existujúce testy sú pomalé, je neúnosné pokúšať sa o ich časté spúšťanie. A bez častého spúšťania TDD nefunguje vôbec, alebo len tak-tak.

Videl som to napríklad v situácii, kde testy boli integračné a spúšťali Spring Boot aplikáciu.

Tu samozrejme s TDD nikam nedôjdeme², ale ani by to nemalo byť potrebné. Namiesto integračnej skupiny testov by sme mohli vytvoriť novú, vytvorenú čisto pomocou TDD, a tieto testy by mali byť dostatočne rýchle.

Ďalší príklad, kde TDD nie je ideálny, je testovať prácu s databázou. Robil som vývoj DAO komponentov pomocou TDD, lebo je to lepšie ako mockovať databázu ale príjemné to nebolo. Nechávam rozhodnutie na vás.

Komfortná zóna

Tento dôvod je psychologický, teda prekonateľný.

Myslenie pri TDD je iné ako sme bežne navyknutí, takže nie je ľahké sa naň vždy prepnúť. Je oveľa ľahšie nájsť výhovorku, prečo práve teraz nie.

Poznám výhody TDD, mám to overené v praxi a viem, že výsledky stoja za to. Ale napriek tomu sa mi dnes jednoducho nechce vyvinúť potrebné úsilie navyše.

Toto sa deje každému bežne v živote, nie je to špecialita TDD. Napríklad ja sa snažím každé ráno ukončiť sprchovanie sa minútovým prúdom studenej vody. Robím to už vyše roka. Viem aké má výhody pre zdravie, že mi to neublíži, a že sa potom cítim dobre. Ale prvých 5 sekúnd je nepríjemných. A to stačí na to, aby som každé ráno zaváhal, či treba aj dnes. A stane sa, že sa presvedčím, že dnes nestíham, alebo som sa nevyspal, prípadne niečo na mňa lezie. Ale keď to nevzdám, tak za 10 sekúnd som rád, že som sa prekonal. Benefit navyše.

Záver

TDD nie je JedináSprávnaCesta™. Nikto to nikdy netvrdil.

Používajte TDD keď vidíte prínosy. V situácii, keď vás TDD brzdí, píšte testy až po alebo nepíšte vôbec. Neznamená to, že vás vylúčia z „klubu“.

Ani tesár nepoužíva len kladivo, hoci sa mu osvedčilo tisíckrát. Rovnako ani TDD nie je vhodný nástroj v každej situácii. Ale dosť závisí aj od našich skúseností a či vieme dôvody prečo to nejde obísť. Ak nevieme, tak by sme nemali nasilu tlačiť. Mohlo by nám to znechutiť výborný nástroj, ktorý funguje v mnohých iných a častejších situáciach.

Ak si vyberiete na prvé experimenty s TDD situácie, ktoré vám sadnú, tak budete mať lepšie výsledky. To vám zvýši chuť skúšať to aj nabudúce. A eventuálne vám dizajnové skúsenosti získané pomocou TDD pomôžu písať kvalitnejšie testy aj bez TDD.

---

1. Aspoň podľa teórie by sa mal zahodiť. Ale všetci dobre vieme, ako to v praxi dopadne… ↩
2. Riešením by mohlo byť použitie aplikácie JRebel, ktorá umožňuje zameniť skompilované triedy v aplikácii počas jej behu. Ale nemám skúsenosti s TDD-čkovaním integračných testov takýmto spôsobom. Navyše ročná licencia JRebel je dosť drahá. ↩