Väčšina programátorov musí v práci písať unit testy. Patríte k tým, čo považujú testy za užitočné a nemajú ich problém vytvoriť? Alebo naopak, lezú vám na nervy, zavadzajú a zdržujú vás?
Ak ste v druhej skupine, možno vám táto séria článkov o Test-Driven Developmente (ďalej len TDD) pomôže nájsť lepší prístup. Mne pred rokmi TDD výrazne zlepšil môj vzťah k unit testovaniu. A vlastne aj k celému dizajnovaniu.
Čo je Test-Driven Development?
TDD je spôsob vývoja softvéru, pri ktorom sa opakovane vykonáva séria krátkych krokov:
- Červený test — naprogramujeme unit test, ktorý očakáva nejakú zatiaľ neexistujúcu funkcionalitu. Test nám hovorí, čo potrebujeme doprogramovať do komponentu. Spustíme ho a overíme, že zlyhal.
- Zelený test — implementujeme chýbajúcu funkcionalitu v komponente. Snažíme sa spraviť minimálne riešenie, ktoré umožní aby test prešiel.
- Refaktoring — ak je to možné tak odstránime nedostatky v kóde a teste, napríklad odstránime duplikovaný kód. Tento krok je dôležitejší, ako by sa mohlo zdať. Keby sme ho ignorovali, tak výsledný produkčný kód by bol mizerný.
- Opakuj od bodu 1 až do ukončenia. Takto postupne pridávame novú funkcionalitu a vylepšujeme kvalitu.
Týmto jednoduchým postupom vieme dosiahnuť lepšie výsledky ako pri tradičnom postupe, kde sa unit testy naprogramujú až po produkčnom kóde. Detailom, prečo je to tak sa budeme venovať v nasledujúcom článku. Jednoduchý príklad ako to prebieha v praxi pri vývoji dátovej štruktúry si môžete pozrieť v tomto článku.
TDD nežiada naprogramovanie všetkých testov dopredu, hoci si ho mnohí, čo ho nevyskúšali, takto predstavujú. Zvyčajne si ho nevyskúšali, pretože si ho predstavili práve takto. Keby sme sa pokúsili o naprogramovanie všetkých testov dopredu, je veľmi pravdepodobné, že výsledok by bol horší ako pri testoch „až po”.
Prečo to funguje?
TDD je na prvý pohľad zvláštny proces. Postavený na hlavu. Veď ako môžeme najprv napísať test a až potom implementáciu? Jednoducho. Presne tak isto, ako môžeme najprv stanoviť, čo chceme naprogramovať a až potom to urobiť.
Práve táto požiadavka, spolu s postupným striedaním písania (krátkeho) testu a prislúchajúcej implementácie je ten dôvod, prečo to funguje a prináša výhody a pohodu. V podstate nám umožňuje, aby sme sa striedavo sústredili na špecifikáciu, čo má komponent robiť; potom na to ako to má robiť a popritom ponúkať spätnú väzbu, či sme niečo pokazili alebo nie.
Zo svojich skúseností viem, že TDD funguje vynikajúco, ak sa robí správne. Situácie, kedy to nemusí fungovať dobre budú spomenuté ďalej.
Prečo ho nepoužíva každý?
Mohli by ste namietať, že keby to bol naozaj taký skvelý spôsob, tak by ho predsa používal každý. Pravda je taká, že TDD očakáva určitý systematický štýl práce a ten nevyhovuje každému.
Okrem toho, ako všetky ostatné techniky na svete, má aj svoje slabé stránky a nehodí sa na vývoj úplne všetkého. Napríklad v situácii, kedy nevieme ako máme dosiahnuť požadovanú funkcionalitu, lebo len experimentujeme s novou technológiou. Alebo nám vôbec nezáleží na kvalite.
Zoznam dôvodov, prečo práve ja na tomto projekte nemôžem použiť TDD je dlhý. Patria tam určite dôvody: ako neskúsený tím, manažment očakávajúci rýchly vývoj na úkor kvality, osobné pohodlie a neochota skúšať nové veci, pomalý vývojový cyklus, nestabilné požiadavky, ale aj mnoho ďalších. Niektoré sú skutočné a niektoré sú len výhovorky. Ja osobne nepoužívam TDD v takýchto situáciach.
Chcem si to vyskúšať. Ako mám začať?
Ak si chcete TDD vyskúšať, odporúčam počkať si na príležitosť vývoja nového komponentu. Ak tým komponentom je dátová štruktúra, tak to pôjde ľahšie, lebo má jasné vstupy a výstupy. Navyše je ľahko viditeľný rozdiel medzi testovaním čo má robiť a ako to robí. To znamená, že testovať budeme scenáre na zápis a čítanie hodnôt, namiesto overovania, či sú údaje správne uložené vo vnútornom stave komponentu.
Pozor, nepokúšajte sa o vyskúšanie TDD na starom komponente s veľkými testami. Tam by ste asi dospeli k záveru, že to nefunguje. Starý komponent si vyžaduje skúsenosti a cit pre testovateľný dizajn. Ten príde až časom.
Linky
- Kent Beck: Test-Driven Development By Example
Záver
Toto bol len úvodný článok, ktorého cieľom je predstaviť ako Test-Driven Development vyzerá. Nasledujúce články prinesú detaily o tom aké výhody TDD má a prečo. Ak ste zvedaví na praktickú ukážku TDD, prípadne si chcete o tom podiskutovať, môžete sa prihlásiť na toto školenie.
Ďalšie Pavlove články na túto tému:
- 8 spôsobov, ako mi Test-Driven Development pomôže zlepšiť moju prácu
- 8 dôvodov, prečo je TDD príjemný spôsob vývoja softvéru
- Nie je Test-Driven Development príliš pomalý spôsob vývoja softvéru?