Testivetoinen kehitys

Testivetoinen kehitys (engl. test-driven development, TDD) on ohjelmointia tukeva tekniikka, jossa luodaan ensin uusi testitapaus ja vasta sen jälkeen muokataan kehitettävää ohjelmaa niin, että se läpäisee uuden testin. Yksikkötestit siis kirjoitetaan pienissä osissa ennen varsinaista tuotantokoodia. Tällä pyritään paitsi parempaan rajapintasuunnitteluun, myös varmistumaan ohjelmiston oikeasta toiminnasta. Mikäli yksikkötestit aiottaisiin kirjoittaa tuotantokoodin jälkeen, ne jäisivät usein tekemättä. Jälkikäteen on vaikeampi nähdä yksikkötestien hyötyjä, joten sille ei yleensä osoiteta aikaa.

Kun testikoodi kirjoitetaan etukäteen, tuloksena saadaan jatkuvasti kehittyvä testiverkosto jonka varassa uusien toimintojen kehittäminen ja virheiden korjaaminen on huomattavasti turvallisempaa, koska jo olemassa olevia testejä suorittamalla huomataan, mikäli virhettä korjatessa tulee tehneeksi uusia virheitä.

Testivetoinen kehitys yhdistetään usein johonkin ketterään ohjelmistoprosessiin. Erityisesti tulee huomata, että testivetoinen kehitys ei ole testausmenetelmä, vaan suunnittelumenetelmä, vaikka sivutuotteena syntyykin joukko käyttökelpoisia testejä.

Kehitystyyli

Testivetoinen kehitys sisältää useita näkökulmia, kuten ”keep it simple, stupid” (KISS)- ja ”You aren’t gonna need it” (YAGNI) -periaatteet. Keskittymällä kirjoittamaan vain testit läpäisevää koodia suunnittelu voi usein olla siistimpää ja selkeämpää kuin muilla menetelmillä. Kent Beckin kirjassa Test-Driven Development by Example hän myös ehdottaa periaatetta ”Fake it till you make it” (suom. Jäljittele sitä, kunnes teet sen.).

Edistyneiden suunnittelukonseptien saavuttamiseksi, kuten suunnittelumallin, kirjoitetaan testejä, jotka generoivat kyseisen suunnitelman. Koodi voi pysyä yksinkertaisempana kuin tavoitesuunnitelma, mutta silti läpäistä kaikki tarvittavat testit. Tämä voi aluksi tuntua epävarmalta, mutta se mahdollistaa kehittäjän keskittymisen vain olennaiseen.

Testien kirjoittaminen ensin: Testit tulisi kirjoittaa ennen testattavaa toiminnallisuutta. Tämän on väitetty tuovan monia etuja. Se auttaa varmistamaan, että sovellus on kirjoitettu testattavaksi, koska kehittäjien on harkittava, miten sovellus testataan jo alusta asti eikä vasta myöhemmin. Se myös varmistaa, että testit kirjoitetaan jokaiselle ominaisuudelle. Lisäksi testien kirjoittaminen ensin johtaa syvempään ja aikaisempaan ymmärrykseen tuotteen vaatimuksista, varmistaa testikoodin tehokkuuden ja ylläpitää jatkuvaa keskittymistä ohjelmistolaadun parantamiseen. Kirjoitettaessa ensin ominaisuuskohtaista koodia kehittäjän ja organisaation on taipumus siirtää kehittäjä seuraavaan ominaisuuteen jopa laiminlyöden kokonaan testauksen. Ensimmäinen TDD-testi saattaa aluksi jopa olla kääntymätön, koska tarvittavia luokkia ja metodeja ei ehkä ole vielä olemassa. Silti kyseinen ensimmäinen testi toimii suoritettavan määrittelyn alkuunpanona.

Jokainen testitapaus epäonnistuu aluksi: Tämä varmistaa, että testi toimii oikein ja voi havaita virheen. Kun tämä on osoitettu, taustalla oleva toiminnallisuus voidaan toteuttaa.