Test Driven Development (TDD)

Test Driven Development (TDD) ehk testipõhine arendus on tarkvaraarenduse metoodika, kus testid kirjutatakse enne tegelikku programmi koodi. Protsess sunnib arendajat mõtlema läbi nõuded ja disaini enne koodi kirjutamist, tagades, et iga koodirida omab eesmärki.

TDD etapid (Red-Green-Refactor)

TDD põhineb väga lühikesel ja korduval tsüklil, mis koosneb kolmest põhietapist:

🔴 Red (Punane): Kirjuta väike test uue funktsionaalsuse jaoks. Käivita test ja veendu, et see ebaõnnestub (kuna funktsionaalsust pole veel loodud). See kinnitab testi enda toimimist.
🟢 Green (Roheline): Kirjuta ainult nii palju koodi, kui on minimaalselt vajalik testi läbimiseks. Koodi kvaliteet pole selles etapis esmatähtis, oluline on toimivus.
🔵 Refactor (Refaktoreerimine): Vaata kood üle ja paranda selle struktuuri (eemalda kordused, paranda nimetusi), olles kindel, et testid jäävad roheliseks. See tagab koodi puhtuse.

Kas TDD-l on alamvariante?

Jah, kuna TDD on laiema kontseptsiooniga lähenemine, on sellest välja kasvanud mitmeid spetsiifilisemaid alamvariante ja edasiarendusi:

ATDD (Acceptance Test Driven Development): Keskendub süsteemi äriliste nõuete (vastuvõtutestide) täitmisele. Testid kirjutatakse koostöös tooteomaniku või kliendiga.
BDD (Behavior Driven Development): TDD edasiarendus, mis keskendub tarkvara käitumise kirjeldamisele inimloetavas keeles (nt "Given-When-Then" formaat). See parandab suhtlust arendajate ja äripoole vahel.

Arendusmudel joonisena

TDD mudelit kujutatakse tavaliselt lõputu tsüklina või ringina, mis sümboliseerib pidevat arendust.

Tsükli visuaalne kirjeldus:

Kujuta ette kolme noolega ringi, mis liigub päripäeva:

Alustad Punasest kastist (Test Failing).
Liigud Rohelisse kasti (Code Passing).
Liigud Sinisesse kasti (Refactoring).
Seejärel alustad uuesti Punasest kastist uue funktsionaalsusega.

Tähtsaim omadus ja miks?

TDD kõige tähtsam omadus on koodi usaldusväärsus ja turvavõrk (Safety Net).

Miks? Kuna iga koodirida on kaetud testiga, saab arendaja teha muudatusi, lisada uusi funktsioone või refaktoreerida vana koodi ilma hirmuta, et miski ootamatult katki läheb. Kui viga tekib, annavad testid sellest koheselt märku ("Fast Feedback"). See vähendab drastiliselt vigade leidmise ja parandamise kulu projekti hilisemates faasides.

TDD Heade ja Veade tabel

Head omadused (Plussid)	Vead ja riskid (Miinused)
Kõrge koodikvaliteet: Sunnib kirjutama modulaarset koodi.	Ajakulu alguses: Esmane arendus on aeglasem.
Vähem vigu: Vead leitakse kohe arenduse käigus.	Raske õppida: Nõuab arendajalt uut mõtteviisi.
Julge refaktoreerimine: Muudatusi on turvaline teha.	Üle-testimine: Oht testida triviaalseid asju.
Dokumentatsioon: Testid on nagu elav juhend.	Hooldus: Kui nõuded muutuvad, tuleb muuta ka teste.
Loe lisaks TDD kohta Wikipediast →

Allikad ja lisalugemist

Info pärineb tuntud tarkvaraarenduse praktikatest ja järgmistest allikatest:

Martin Fowler: TDD Wikipedia: TDD Agile Alliance: TDD

365 päeva TDD-d