Mis on Acceptance Test Driven Development (ATDD)?

Acceptance Test Driven Development (ATDD) ehk vastuvõtutestidel põhinev arendus on tarkvaraarenduse metoodika, kus "kolm sõpra" (The Three Amigos) – arendaja, testija ja tooteomanik (või äriklient) – koostavad enne koodi kirjutamist ühiselt vastuvõtutestid.

Need testid defineerivad täpselt, mida süsteem peab tegema, et see loetaks "valmis" olevaks. Erinevalt klassikalisest TDD-st (mis keskendub ühiktestidele ja koodi tehnilisele õigsusele), keskendub ATDD süsteemi käitumisele ja ärilistele nõuetele.

Põhimõte: Me ei kirjuta koodi enne, kui meil on olemas ebaõnnestuv vastuvõtutest, mis kirjeldab soovitud ärifunktsionaalsust.

ATDD Etapid

ATDD protsess järgib tavaliselt nelja peamist sammu, mida tuntakse ka kui 4 D-d:

1. Arutelu (Discuss): Meeskond (äri, arendus, testimine) arutab läbi kasutajaloo (User Story) ja selgitab välja, mida on vaja ehitada.
2. Täpsustamine (Distill): Arutelu tulemused vormistatakse konkreetseteks, testitavateks aktsepteerimiskriteeriumiteks (testideks), mis on masinloetavad (nt Gherkin keeles).
3. Arendus (Develop): Arendajad kirjutavad koodi ja ühikteste (TDD), kuni vastuvõtutestid lähevad läbi.
4. Esitlus (Demo): Töötavat lahendust näidatakse huvigruppidele ja viiakse läbi uuriv testimine.

Alamvariandid ja seotud metoodikad

ATDD on katusmõiste ja seda aetakse tihti segi või kasutatakse koos teiste sarnaste lähenemistega. Otseseid "alamvariante" on raske eristada, pigem on need erinevad implementatsioonid:

BDD (Behavior Driven Development): Väga lähedane ATDD-le. Kui ATDD keskendub testimisele, siis BDD rõhutab ühist keelt ja süsteemi käitumise kirjeldamist (nt "Given-When-Then" formaat).
SBE (Specification by Example): Keskendub nõuete defineerimisele konkreetsete näidete varal, mis muutuvad hiljem testideks.

Arendusmudeli joonis

ATDD tsükkel on iteratiivne. Allpool on kirjeldatud visuaalne protsess:

ATDD Arendustsükkel

Tähtsaim omadus ja miks?

Koostöö ja ühine arusaam (Shared Understanding)

ATDD kõige kriitilisem omadus ei ole mitte automatiseerimine, vaid kommunikatsioon.

Miks? Tarkvaraarenduse suurim ja kulukaim probleem on "vale asja ehitamine". Kui arendaja saab nõudest valesti aru, on hilisem parandamine kordades kallim. ATDD sunnib äripoole ja arendajad enne esimest koodirida kokku leppima täpsed kriteeriumid.

Head ja Vead (Plussid ja Miinused)

Omadus	Plussid (Head)	Miinused (Vead)
Kvaliteet	Vähendab oluliselt defektide arvu ja ümbertegemise vajadust, kuna nõuded on selged.	Võib tunduda alguses aeglane, kuna "koodi ei toodeta" kohe.
Dokumentatsioon	Testid toimivad kui "elav dokumentatsioon" (Living Documentation), mis on alati ajakohane.	Testide ja dokumentatsiooni haldamine nõuab distsipliini ja aega.
Koostöö	Lõhub barjäärid arendajate, testijate ja äripoole vahel.	Nõuab suurt kultuurilist muutust ja kõigi osapoolte (eriti äripoole) aktiivset aega.
Hooldus	Lihtsustab hilisemat koodi muutmist (regression testing on automaatne).	Halvasti kirjutatud vastuvõtutestid võivad muutuda rabedaks (brittle tests) ja vajada pidevat parandamist.
Loe rohkem Wikipediast

Viited ja lisamaterjalid

Info koondamisel on kasutatud järgmisi allikaid:

Agile Alliance: ATDD Cucumber & BDD (Seotud teema) GeeksForGeeks: ATDD

2026 Aasta on alanud!