Pred nejakým časom som písal článok o tom, že pri budovaní automatického testovania nie je dobré vynechať jednotkové testy. Keďže každé spektrum má dva extrémy, aj v tomto prípade je to tak. Totiž pustiť sa do písania testov, a nemať to premyslené, môže skončiť katastrofou. Viem o niekoľkých projektoch, ktoré takto zahodili možnosť testovanie automatizovať.

Na začiatku (ako to už býva) je zopár pekných myšlienok: „Vieme, že na projekte máme problém s kvalitou kódu. O jednotkových testoch sme počuli, že s tým vedia pomôcť. Všetci hovoria, že písanie testov je super a mali by sme to robiť. Preto ideme robiť jednotkové testy.“

To, čo nasleduje, už také super nie je. Nejaký programátor (alebo v horšom prípade všetci programátori naraz) je vybraný a ide na to. Niečo si naštuduje, nakódi nejakú funkcionalitu a začne písať testy. Nejako mu to ale trvá a úloha, čo bola odhadovaná na 4 hodiny, sa robila 16 hodín. Ale na konci má jeden alebo viac testov. Manažment zatne zuby a ide sa ďalej s myšlienkou, že začiatky sú ťažké.

Problém je, že aj ďalšie úlohy sa predlžujú a medzičasom sa zistí, že kód z prvého zadania niekto zmenil a pôvodné testy nefungujú. To už je ale čas releasu, a preto sa testy neriešia. Dôležité je dodať funkčný kód. Nasleduje ešte niekoľko pokusov s testami, dokopy sa ich nazberá 30 na rôzne časti kódu. Časť z nich je už nefunkčná, a tak sú buď zakomentované alebo sa pri zostavovaní zapne prepínač, aby ich ignoroval. Všetko sa vracia do pôvodných koľají s jednou výnimkou. Diskusie na tému jednotkových testov sú o čosi depresívnejšie a do projektu sa vkrádajú myšlienky, že to s tými testami je nejaká nerealizovateľná teória, alebo že na tomto projekte sa to proste nedá (kvôli zákazníkovi, kvôli budgetu, kvôli…).

Na mojej ceste cez rôzne projekty za posledné roky som videl naozaj veľa takýchto stavov. Nejaké testy v repozitári, všeobecné povedomie alebo akési tušenie toho, že testy sú dobré ale zároveň negatívne skúsenosti s ich písaním. Kde je problém?

Problém je, že testy nie sú magický prútik, ktorým stačí mávnuť a všetko funguje. Ak začínate od nuly s ich písaním, tak treba čakať, že to nebude jednoduché. Písanie testov je zručnosť, ktorú je nutné sa naučiť. To bude stáť určitý čas a teda aj peniaze. Znamená to, že sa nejaká časť implementácie predraží. A práve nad tým sa treba zamyslieť.

Jednotkové testy sú ako každý iný nástroj. Má svoj účel a svoje limity. Aplikovať ho len tak všeobecne v duchu „poďme písať jednotkové testy“ je cesta do pekla. Ak za mnou niekto príde, že chce začať písať testy, tak ako prvú vec sa ho pýtam, prečo to chce robiť. A niekedy sa stáva, že na to, čo chce dosiahnuť (lepšiu štruktúru kódu, menej chýb atď.), mu poradím nejakú inú techniku (review kódu, statickú analýzu atď.).

Ale ak už ostaneme pri jednotkových testoch, tak mu poradím, nech si vyberie oblasť, ktorá je pre projekt (a teda aj jeho manažment) kritická. Nejaká časť, komponent, ktorá musí byť kvalitná, inak celá aplikácia stráca zmysel, hoci sa aj teraz nejde meniť, a teda testy sa budú písať na kód, ktorý už nejaký čas existuje.

Je to za prvé preto, lebo z praktického hľadiska je naozaj zmysluplné držať vysokú kvalitu na dôležitom komponente ako na niečom menej dôležitom. A za druhé preto, lebo manažment bude ochotnejší investovať ďalšie peniaze naviac do dôležitej časti, ako keby ho mala stáť dvojnásobok implementácia nejakého tlačidla pre okrajové prípady.

Ak dospejete do stavu, že váš tím je navyknutý písať testy (a váš manažment je navyknutý to platiť), tak ich môžete rozšíriť na väčšinu aplikácie (o 100% pokrytie sa nemá zmysel snažiť, ale 90% je celkom reálne). Dovtedy sa treba pozerať na jednotkové testy ako nástroj, ktorý vás bude niečo stáť, a preto ho treba používať s rozvahou a tam, kde to má najväčší zmysel. V opačnom prípade hrozí, že si na tom vylámete zuby a po takom neúspechu sa nový reštart tejto témy robí o dosť ťažšie.