fbpx

Prečo mám rád unit testy

Vo svojej programátorskej kariére som spravil niekoľko veľkých skokov, ktoré znamenali posun v kvalite mojej práce a zároveň aj môjho nadšenia pre túto prácu. Tieto skoky sa odohrali keď som objavil (a zvládol) nasledujúce veci:

  • OOP a OOD
  • Design Patterns
  • Unit Testing

Posledne menovanému je venovaný celý môj blog. Dnes sa chcem podeliť o to, prečo mám rád unit testy. Čiastočne tým chcem kompenzovať minulý článok, kde som sa pokúsil o kontroverziu, niečo v zmysle, že mi unit testy vadia. Ak to niekto nepochopil, tak týmto článkom chcem napraviť čo som „pokazil”.

Ale hlavným cieľom tohto článku je šíriť myšlienku, že unit testy majú potenciál byť obľúbený programátorský nástroj. Len sa ich musíme naučiť robiť dobre a dať im šancu.

Takže dobre napísané unit testy mám rád lebo poskytujú nasledovné:

Istotu

Refaktoring a implementácia nových požiadaviek do tried si vyžadujú zmeny existujúceho kódu. To prináša potenciál pre chyby. Keďže nie som neomylný, tak oceňujem istotu, ktorú mi vedia unit testy poskytnúť. Mnohokrát sa mi stalo, že ma existujúce testy upozornili na chybu, ktorá by inak ostala bez povšimnutia. A zažil som aj to, že čerstvo napísaný unit test objavil dlho skrytú chybu.

Flexibilný dizajn

Vždy ma príjemne poteší, keď sa nájde nové uplatnenie pre môj komponent. Najmä ak som také použitie nepredpokladal. Toto sa môže stať hociktorému komponentu, ktorý je nadizajnovaný tak, že je možné nahradiť všetky jeho spolupracujúce komponenty1.

A práve unit testy (najmä tie, čo sú vytvorené pomocou TDD) toto prirodzene umožňujú. Stačí len to, že nás prinútia naprogramovať komponent ako testovateľný. A potom už len mať otvorené oči a čakať na príležitosť 🤓.

Pochopenie špecifikácie

Každý už zažil situáciu, že začal programovať komponent bez toho aby úplne chápal, čo treba spraviť. Zvyčajne to malo následky.

Toto je pri TDD menej pravdepodobné, lebo pochopenie špecifikácie je základ pri TDD. Takže ak chcem použiť TDD, tak musím vynaložiť väčšie úsilie na pochopenie, čo mám vlastne vytvoriť.

Podobne, keď potrebujeme pochopiť čo robí existujúci komponent, tak kvalitné a čitateľné unit testy nám môžu pomôcť. Takéto testy nemusia byť vytvorené pomocou TDD, ale potom je ich dobrá čitateľnosť menej pravdepodobná.

Rýchlosť

Pre niekoho môže byť ťažké si predstaviť, že unit testy vedú ku rýchlejšiemu vývoju softvéru, lebo ich treba napísať a udržiavať. Ale keď sú urobené dobre, tak tá jednorazová investícia do napísania testov sa vráti mnohonásobne pri ďalšom vývoji.

Dôvodom je rýchla spätná väzba o chybe, ktorú neodhalíme až neskôr pri testovaní ale veľmi rýchlo po jej vytvorení. Teda v čase keď si „autor” chyby ešte pamätá čo menil a prečo. Za takýchto okolností je jej oprava oveľa rýchlejšia ako keď musí tester spísať čo robil; s akými údajmi; čo sa stalo; a čo očakával.

Potom sa chyba dostane ku programátorovi. Tomu to tiež nepôjde od ruky, lebo: nemá kontext, alebo si musí naň spomenúť; musí overiť, či tester správne pochopil ako má testovaná funkcionalita fungovať; overiť, či sú vstupné údaje v poriadku; zistiť kde problém vznikol, pričom má k dispozícii oveľa viac možností vďaka množstvu komitov, ktoré pribudli. Nakoniec už len stačí nájsť správne miesto, kde chybe zabrániť. Opäť má viacej možností ako keď si programátor nájde chybu hneď ako ju zaviedol.

Spokojnosť

Tento bod vychádza z predchádzajúcich. Keď je výsledkom mojej práce vyššia kvalita (menej chýb, vyššia flexibilita, …) a naplní sa predpoklad, že je vývoj lacnejší, tak budú spokojní všetci odo mňa, cez tím, manažment až po zákazníka. Hoci ten si určite neuvedomí, akú rolu zohrali unit testy. Ale to je v pohode.

Záver

Toto bol krátky zoznam, s nie príliš detailným vysvetlením, prečo mám rád unit testy. Ak vám tam niečo chýbalo, alebo by ste chceli viac detailov, tak mi napíšte komentár.

Musím sa priznať. Napriek výhodám, čo mi unit testy prinášajú, ich píšem menej ako by sa patrilo. Ale ak sa vrátim k úvodu a porovnám ich s design patternami, tak môžem spokojne konštatovať, že unit testy používam výrazne viac.

A tak je to dobre. Veď unit testov nie je nikdy dosť. Na druhej strane, príliš veľa použití (rôznych) design patternov v projekte zvyčajne škodí. Takže to vlastne robím dobre.


  1. K tomu sa patrí dodať, že delegovať to, čo sa na algoritme môže meniť, na spolupracujúci komponent je hlavný dôvod, prečo znovupoužitie funguje, Je to vlastne aplikácia Open Closed Principle.