Mikä on WikiWiki?
nettipäiväkirja
koko wiki (etsi)
viime muutokset
Tämä sivu yrittää olla jatkoa testausstrategioista-sivulle.
Automatisoitu testi tarkoittaa ohjelmanpätkää, joka ei tee muuta kuin tarkastaa, että toinen ohjelmanpätkä toimii niin kuin sen kuuluu. Se voi esimerkiksi testata sitä erilaisilla syötteillä ja tarkastella sen antamia vastauksia.
Automatisoiduista (yksikkö)testeistä on seuraus, että ohjelma on pakko järjestellä yksittäisiin komponentteihin, joilla on hyvinmääritelty toimintatapa ja tarkoitus. Tätä kutsutaan sopimuksenmukaiseksi ohjelmoinniksi, ja se tekee mahdolliseksi kehittää iteratiivisesti ohjelmistoja.
Automatisoitujen testien kirjoittamisen tarpeellisuus on arvioitava joka tapauksessa erikseen. Se on helppo aliarvioida: on suuri kiusaus kutsua valmiiksi systeemiä siinä vaiheessa, kun saa sen ensimmäistä kertaa "toimimaan" (vaikka todellisuudessa testauksella ei olisi edes koodikattavuutta). Automatisoidut testit toimivat suunnittelustrategiana, antavat luottamusta koodiin, sekä tekevät helpoksi ja turvalliseksi tehdä muutoksia - testithän voi ajaa aina uudestaan, kunnes ne menevät läpi, jolloin on melkoinen varmuus siitä, että ohjelma toimii, kuten sen kuuluukin.
Mutta automatisoiduissa testeissä on ongelmia. Jotkut niistä ovat tolkuttoman vaikeita tehdä, aina siihen pisteeseen saakka, jolloin on mahdotonta selittää niiden hyödyllisyyttä projektiin osallistuville ihmisille. Ja jos tekee jotain yksinkertaista mutta vaikeasti testattavaa, testien kirjoittaminen ei yksinkertaisesti ole kohtuullinen vaiva.
Normaalitilanteessa testit olisi myös hyvä kirjoittaa etukäteen, kuten testausstrategioista sanotaan. Mutta usein komponentin sopimus on helpompi kehittää samalla, kun komponenttia kehittää. Jos yrittää tehdä testin etukäteen, voi käydä niin, että sopimusta muutettaessa joutuu tekemään koko ajan muutoksia kahteen paikkaan, varsinaiseen koodiin ja sen testauskoodiin. Tämä on kohtuullista valmiissa ohjelmassa, muttei nopeasti kehittymässä olevassa prototyypissa. Ja lopuksi, mikä tahansa tekijä, joka hidastaa varsinaiseen koodaushommaan ryhtymistä, on itseisarvoisesti jonkin verran paha asia. Tämän olen oppinut kantapään kautta eritoten oliopohjaisen kehitysmetodologian myötä, joka kykenee saamaan pahimmillaan yksinkertaisimmankin projektin tolkuttoman vaativaksi edellyttämällä varautumista muutokseen mahdottoman monella tavalla jo ennen, kuin ohjelmasta on tehty yhtäkään toimivaa komponenttia. Tällainen overhead ei ole hyväksyttävää.