Mida TDD tähendab?

TechEd 2008 sai külastatud ka Roy Osherove‘i ettekannet teemal “Understanding Why You Need Test Driven Development and More“, mis oli “TDD by Example“. Selle juures mu jaoks kõige huvitavam oli, mida on võimalik TDD all silmas pidada. Ilmselgelt tuleb endale see kõigepealt selgeks teha, sest ilma selleta on kuidagi väär öelda, et teen TDD.

Test Driven Development

Esimine neist võiks koosneda sellest, et kirjutame testid enne toote koodi ja jälgime TDD rütmi (punane > roheline > ümberstruktureerimine). Varajasemas postituses mainisin, et TDD ja TFD (Test First Development) ei ole päris sama ning see tekkis sellest, et mu jaoks ei ole TDD ainult see mida siin defineeritud.

Test Oriented Development

Paljud mainivad, et kui neil on olemas komponenditestid või integratsioonitestid, et nad teevad TDD. Siiski on see narr arvamus ja õigem oleks öelda, et kirjutatakse teste (peamiselt pärast tootekoodi kirjutamist). Ka see on väärtuslik lähenemine, vähemalt alguses.

Test Driven Design

See on siis see, mida paljud suuremad fanaatikud TDD-st arvavad. Nende jaoks on testide kirjutamine enne koodi täiesti loomulik nähtus ning nendega määratakse nõuded toote koodile. Selle puhul kujuneb disain testide loomise käigus ja eelnevalt sellega oluliselt ei tegelda. Nii mõnedki arvavad, et see on halb lähenemine, kuid mulle tundub see rohkem oskamatus korralikku struktuuri luua. Selle puhul on oluline tunda objekt-orienteeritud printsiipe (lisaks testimise raamistikkudele on ka võltsitud objektide raamistikud arvamusega – RhinoMocks‘i puhul tuleb printsiipe teada, et paremini testida, TypeMock‘i abiga on ka võimalik Sharepoint‘i testida ehk disain pole oluline) ja disaini mustreid. Ilma nendeta kaob mõistlikus kiiresti.

Test Driven Development & Design

Selle all võiks mõelda põimumist esimese ja kolmanda vahel ning võib-olla rohkem ettevalmistatud disainiga. Kui eelmises oli disaini eelnevalt tegemata ja testidega loodi seda, siis siin võiks olla disain varem vabamalt välja joonistatud olla (siiski testid võivad seda disaini ümber kujundada). See võiks olla neist ilmselt kõige praktilisem lähenemisnurk.

TDD tähendus oleneb küllaltki palju, mida testidega soovitakse saavutada (omada teste projektis, muuta testid nõueteks, testide abil kujundada tarkvara disaini vms).