Prečo ATDD funguje

Prečo testovať správanie, nie implementáciu

Ak test overuje vnútornú štruktúru (konkrétne triedy, metódy), každá zmena implementácie – aj keď správanie zostane rovnaké – ti test rozbije. Test sa tak stáva prekážkou refaktoringu namiesto jeho poistky. Ian Cooper v prednáške „TDD, Where Did It All Go Wrong“ preto odporúča testovať stabilné verejné rozhranie modulu: dôvodom na nový test je vždy nová požiadavka na správanie, nie nová trieda alebo metóda.

Z toho vyplýva aj hranica testovania: privátne API (interné triedy, pomocné metódy) sa netestuje vôbec – je to implementačný detail, ktorý sa môže kedykoľvek zmeniť. Testuje sa len verejné (public) API modulu, a ani to nie automaticky celé – nový test pridávaš len tam, kde za tým stojí konkrétna požiadavka na správanie, nie ku každej public metóde len preto, že je public.

Samotný cyklus písania testov – Test List, jeden padajúci test, oprava, voliteľný refaktoring, opakovanie – opisuje Kent Beck vo svojom článku „Canon TDD“ (pozri aj Referenciu).

V praxi existuje viacero škôl, ktoré sa líšia v tom, čo presne je „unit“ a koľko sa má izolovať (pozri Referenciu) – ATDD si z nich berie prístup, ktorý najlepšie zodpovedá testovaniu správania, nie štruktúry.

Use Case Driven Development

Namiesto testovania jednotlivých tried alebo vrstiev osobitne sa testy viažu na use case-y – kúsky správania, ktoré má systém poskytovať navonok. Tento prístup opisuje Valentina Cupać v prednáške „TDD and Clean Architecture – Use Case Driven Development“.

Doména (biznis pravidlá) je interný implementačný detail systému, use case je vstupný bod, cez ktorý sa k nej pristupuje. Takéto testy sú zároveň spustiteľnou špecifikáciou požiadaviek a sú odolné voči zmenám implementácie – čo im dáva vysoké ROI (Return of Investment).

Ak je v doméne veľká kombinatorická zložitosť (napr. veľa kombinácií vstupov a validačných pravidiel), oplatí sa časť logiky otestovať priamo dedikovaným unit testom na doménovom objekte – napríklad Email Value Object a jeho validácia. Use case testy potom nemusia opakovať všetky kombinácie, stačí im jeden reprezentatívny prípad.

ATDD v kontexte Continuous Delivery

Koncept vychádza aj z prostredia Continuous Delivery (Jez Humble, Dave Farley, continuousdelivery.com): v deployment pipeline beží najprv rýchla vrstva unit testov pri každom commite, až po nej nasledujú pomalšie, komplexnejšie akceptačné testy.

Ak sa nájde chyba v akceptačných testoch, signálom je doplniť alebo vylepšiť unit testy – nie pridávať ďalšie pomalé akceptačné testy.

Automatizované testy nenahrádzajú ľudí – exploračné a používateľské testovanie zostávajú súčasťou procesu, len sa vďaka automatizácii môžu sústrediť na to, čo stroj nevie overiť.