Tento článok je úmyselne krátky, lebo chcem aby fungoval ako referencia. Takto sa k nemu môžete vrátiť neskôr a pripomenúť si jednotlivé kroky. Z toho dôvodu v ňom nechcem ísť do detailov. Na to bude priestor v nasledujúcich článkoch.
Vývoj komponentu podľa Test-Driven Development (TDD) sa skladá z opakovania krátkej sekvencie krokov. Zjednodušene to vyzerá takto:
Pozrime na jednotlivé kroky.
1. Červený test
Cieľom tohto kroku je ukázať, že nám chýba nejaká funkcionalita. Test hovorí ČO sa od komponentu očakáva.
Napíšeme test a spustíme ho. Mal by zlyhať. Ak nezlyhal, treba sa zamyslieť, či je v ňom chyba, alebo testovaná funkcionalita je už hotová.
2. Zelený test
Test nám ukázal, čo nám chýba. V tomto kroku pracujeme na tom AKO to implementovať. Takže ideme dopísať alebo upraviť produkčný kód tak, aby test prešiel (teda všetky relevantné testy). Testy by sme v tomto kroku meniť nemali.
Vďaka skúsenostiam máme zvyčajne predstavu ako má riešenie vyzerať. Ale je lepšie, ak držíme naše ego na uzde a snažíme sa napísať minimálne riešenie, ktoré umožní testom prejsť. Keď napíšeme príliš veľa komplikovaného kódu, tak je pravdepodobné, že naň nemáme testy. A bez testov nemáme možnosť automaticky overiť, či všetko funguje ako má. A súčasne sme sa vystavili riziku, že tie testy ani nevzniknú — a tým stratíme jednu z výhod TDD.
3. Refaktoring
Refaktoring je neodmysliteľná súčasť TDD. Je taký dôležitý ako samotné písanie produkčného kódu. Zvyčajne ide o odstránenie duplikovaného kódu alebo generalizáciu riešenia. A netýka sa len produkčného kódu. Testy tiež treba udržiavať vo forme.
Niekedy sa dá tento krok preskočiť, lebo nie je nič čo by sa dalo zlepšiť. Ale vždy treba spraviť rozhodnutie na základe aktuálneho stavu. Nechce sa mi nie je dôvod ?.
Opakuj od bodu 1
Tieto 3 kroky sa opakujú až kým nemáme celé riešenie hotové. Zvyčajne trvá jeden cyklus len pár minút alebo desiatok minút. Ak sa na projekte používa git, tak je možné komitnúť pridanú funkcionalitu skôr ako pokračujeme s nasledujúcim testom1.
- Komitovať často je dobrý nápad aj bez git-u. Git je vhodnejší, lebo nám umožňuje spojiť viaceré komity do jedného, takže história nezostane zaspamovaná maličkými zmenami. ↩
„Vďaka mojim dlhoročným skúsenostiam s tvorbou unit testov a refaktoringom pomáham programátorom zmeniť ich postoj z musím na oveľa lepší — baví ma a dokážem.”
1 komentár k “TDD cyklus”
Nie je možné pridávať komentáre.