Continuous Test Driven Development (CTDD)

Mis on CTDD?

Continuous Test Driven Development (CTDD) ehk pidev testipõhine arendus on tarkvaraarenduse metoodika, mis ühendab endas kaks populaarset praktikat: TDD (Test Driven Development) ja CI (Continuous Integration).

Selle mudeli puhul kirjutavad arendajad testid enne koodi kirjutamist (TDD), kuid lisaks käivitatakse neid teste automaatselt taustal iga kord, kui koodi muudetakse või salvestatakse (Continuous Testing). See tagab, et vigu märgatakse koheselt, mitte alles hiljem testimisfaasis.

CTDD Etapid

CTDD järgib laiendatud TDD tsüklit, mida tuntakse sageli "Red-Green-Refactor" nime all, millele lisandub pidev integratsioon:

1. Punane (Red): Kirjuta väike test, mis ebaõnnestub (sest funktsionaalsust pole veel loodud).
2. Roheline (Green): Kirjuta minimaalne kogus koodi, et test õnnestuks.
3. Refaktoreeri (Refactor): Puhasta ja optimeeri koodi ilma selle käitumist muutmata.
4. Pidev integratsioon (CI): Kood lükatakse (push) repositooriumisse, kus CI-server (nt Jenkins, GitHub Actions) jooksutab automaatselt kõiki teste uuesti, et veenduda süsteemi terviklikkuses.

Kas sellel on alamvariante?

Kuigi CTDD on ise TDD edasiarendus, eksisteerib sellega tihedalt seotud variatsioone, mis keskenduvad testimise erinevatele aspektidele:

ATDD (Acceptance Test Driven Development): Keskendub ärinõuetele. Testid kirjutatakse kliendi vaatepunktist enne koodi.
BDD (Behavior Driven Development): Keskendub süsteemi käitumise kirjeldamisele inimkeeles (nt "Given-When-Then" formaat), mis seejärel muudetakse automaattestideks.

Arendusmudeli joonis

Allpool on CTDD tsükli visuaalne joonis (Red-Green-Refactor + CI):

CTDD Tsükkel

Tähtsaim omadus ja miks

Kiire ja automaatne tagasiside (Immediate Feedback)

CTDD tähtsaim omadus on tagasisideahela lühendamine.

Miks see on oluline? Tavapärases arenduses leitakse vead alles tunde või päevi hiljem. CTDD puhul saab arendaja teada vea olemasolust sekunditega. See hoiab koodi kvaliteedi pidevalt kõrgena ja vähendab drastiliselt aega, mis kulub vigade (bugide) otsimisele.

Head ja Vead

Omadus	Head (Plussid)	Vead (Miinused)
Kvaliteet	Väga kõrge koodikvaliteet ja vähem vigu (bugisid).	Nõuab distsipliini, et mitte kirjutada "halbu" teste, mis annavad valepositiivseid tulemusi.
Dokumentatsioon	Testid toimivad elava dokumentatsioonina – näitavad täpselt, mida kood teeb.	Testide ja koodi sünkroonis hoidmine nõuab lisatööd.
Kiirus	Pikas perspektiivis säästab aega, kuna silumist (debugimist) on vähem.	Alguses aeglasem, kuna iga liigutus nõuab testi kirjutamist.
Refaktoreerimine	Võimaldab julgelt koodi muuta, kartmata, et miski katki läheb.	Suure pärandkoodi (legacy code) puhul on keeruline rakendada.

Viited ja lisainfo

Siit leiad allikad ja lisalugemist antud teema kohta:

Martin Fowler: TDD Agile Alliance: ATDD Guru99: TDD Guide