Times like these

Yksikkötestit, koodin vaatimusmäärittely

Maaliskuu 16th, 2006

Olin eilen ensimmäistä kertaa Agile Finlandin järjestämässä coding dojo-tapahtumassa. Ilta osoittautui siinä mielessä hedelmälliseksi, että huomasin virheen ajattelussani.

Ohjelmistoprojekteissa on yleisesti hyväksytty ajatus, että mitään ei ohjelmoida, ellei sen toiminnallisuuttta ole ensin dokumentoitu (vaatimus > käyttötapaus > tekninen suunnitelma). Test driven-mallissa homma viedään vielä pykälää matalammalle tasolle: Mitään toiminnallisuutta ei koodata ilman yksikkötestiä.

Yksikkötesti mahdollistaa koodin toiminnallisuuden tarkistuksen kehityksen missä tahansa vaiheessa. Sillä myös vältetään regressio-virheet, joita usein tulee, kun muutetaan monen eri komponentin käyttämää koodia.

Virhe ajattelussani, jonka alussa mainitsin, liittyi juuri näiden yksikkötestien kirjoittamiseen. Olen nimittäin tähän saakka kirjoittanut testejä testatakseni jo olemassa olevaa koodia, en määrittämään vaatimuksia sille, mitä uuden koodin tulisi tehdä. Olin toki kuullut mantran, “test first”, mutten tosiaan ollut tullut ajatelleeksi asiaa sen tarkemmin.

Ilta oli tosiaan antoisa ja tarkoituksenani on käydä jatkossakin dojoilemassa. Uskoisin, että noista illoista tulee kyllä äkkiä niin suosittuja, että niitä täytyy ruveta järjestämään muidenkin kuin Agile Finlandin ydinporukan.

Artikkeli on luettu 647 kertaa. Kuuluu luokkiin: Menetelmät, Ohjelmointi, Test-Driven Development