Yksikkötestaus

Yksikkötestaus on ohjelmistojen testauksen menetelmä, jossa yksittäisten ohjelman osasten toimintaa testataan, mikäli mahdollista erillään muusta koodista, jotta voidaan todeta että se täyttää sille asetetut vaatimukset. Yksikkötestaus tehdään tyypillisesti käyttäen jotakin yksikkötestauskirjastoa, joka hoitaa testien suorittamisen ja tulosten koostamisen. Kirjastot yleensä myös toimivat yhteen IDE:jen kanssa, tehden testien ajamisesta ohjelmoinnin yhteydessä helppoa ja nopeaa. Suuremmissa projekteissa yksikkötestejä suoritetaan automaattisesti aina kun projektiin tuodaan uutta koodia. Yksikkötestauksen etuja ovatkin juuri kirjastojen tarjoama automaatio ja hyvän yksikkötestauksen tuoma varmuus testattujen luokkien toiminnasta.

Kattavuudesta

Testien laatimisessa ei pidä tyytyä vain muutamiin helpoiten mieleen tuleviin tapauksiin vaan toimia systemaattisesti ja kiinnittää huomiota testijoukon kattavuuteen. Kattavuutta voidaan arvioida useille erilaisilla koodiin ja sen suorittamiseen liittyvillä mitoilla, kuten:

• funktiokattavuus: Onko kaikkia metodeja kutsuttu?
• lausekattavuus tai rivikattavuus: Onko jokainen ohjelman lause tai rivi suoritettu?
• haarakattavuus: Onko jokaisen ehtolauseen (tai vastaavan) jokainen haara suoritettu?
• ehtokattavuus: Onko jokainen ehtolauseke evaluoitunut sekä todeksi että epätodeksi?
• polkukattavuus: Onko jokainen mahdollinen ohjelman suorituspolku suoritettu? Tätä ei yleensä ole mahdollista saavuttaa.

Näiden kattavuusmittojen selvittämiseen on olemassa valmiita työkaluja, joita voidaan käyttää testauksessa ja jotka kertovat esimerkiksi, kuinka monta prosenttia ohjelman lauseista testit käyvät läpi ja mahdollisesti näyttävät lauseet, joita testit eivät käy läpi.

Valitettavasti näiden kattavuusmittojen 100% toteutuminen (lukuunottamatta polkukattavuutta, jota puolestaan ei yleensä voi saavuttaa testeissä) ei aina yksin riitä tuottamaan ohjelman toiminnan kannalta kattavaa testijoukkoa, kuten seuraavasta esimerkistä käy ilmi.

Allaolevassa esimerkissä esitellään metodi suhde, joka laskee kahden kokonaisluvun suhteen mahdollisimman tarkasti ja palauttaa sen mikäli mahdollista. Mieti miten koodin tulisi toimia normaaleissa ja epänormaaleissa tapauksissa?

#
# Palauta annetuista luvuista pienemmän suhde suurempaan, mikäli mahdollista.
#
def suhde(n, m):
    if n < m:
       return m/n
    else:
       return n/m

Jos testijoukkomme sisältää testit:

suhde(2,4) == 2.0

suhde(4,2) == 2.0

Saadaan 100% funktiokattavuus, lausekattavuus, haarakattavuus ja ehtokattavuus. Kuitenkin jotain oleellista on jäänyt huomaamatta; mitä?

Tehtävä: testikattavuus

Ratkaise tehtävä A+:ssa.

Kattavuutta pohdittaessa ei siten pidä tyytyä vain mainittujen kattavuusmittojen 100% saavuttamiseen (johon toki siihenkin pitää pyrkiä) vaan on tarkasteltava ohjelman speksiä ja pyrittävä löytämään sen avulla oleellisia testitapauksia.

Testaus ei ole aina helppoa ja suoraviivaista. Ohjelman speksi voi itsessään jo tehdä testauksesta hankalaa, mutta paljon riippuu myös ohjelman rakenteesta, esimerkiksi kuinka helppoa ohjelman osat on irroittaa toisistaan testiä varten. Monesti olion sisäinen tila riippuu suoritushistoriasta, joloin yksittäistä operaatiota testaava testi voi mennä läpi, mutta useamman operaation peräkkäinen suorittaminen epäonnistua. Esimerkiksi ohjelmaa käytettäessä havaitun virheen uudelleen toistavan testitapauksen luominen voi tällöin olla työlästä.

Rinnakkaisohjelmoinnissa suoritushistorian rooli korostuu vielä enemmän, virheet toistuvat satunnaisesti ja mahdollisesti hyvin harvoin. Tästä puhutaan lisää myöhemmin kurssilla.

Helpompaa testausta

Osa asioista jotka tekevät testaamisesta helpompaa, ovat myös yleisesti hyvän koodin tunnusmerkkejä, joihin tutustuimme edellisessä luvussa. Kun luokkien ja piirreluokkien rajapinnat kirjoitetaan mahdollisuuksien mukaan yksinkertaisiksi ja selkeiksi, ja luokkien välillä on vähän riippuvuuksia, niitä on helpompi testata. Kovin isot luokat kannattaa jakaa useammaksi luokaksi pyrkien erottamaan eri toiminnallisuuden osat vaikkapa omiin piirreluokkiin. Tämän jälkeen jokainen piirreluokka on tarvittaessa testattavissa erikseen.

Edellisessä luvussa esiteltiin pikaisesti muutama “sijaisluokka”, joille löytyy paljon käyttöä yksikkötestauksessa, koska käytännössä luokat tarvitsevat oman toiminnallisuutensa toteuttamiseen muita luokkia. Monimutkaiseen rajapintaan on vaikea kirjoittaa oikeaa toteutusta simuloivia apuluokkia

Myös se, että luokka kutsuu käyttämiensä luokkien konstruktoreita suoraan tekee riippuvuuksien korvaamisesta haastavaa. Jos riippuvuudet vaikkapa välitetään luokan konstruktorille, ei ongelmaa tule. Vastaavasti perinnän kautta tulevat riippuvuudet on hankalampi käsitellä kuin viittausten kautta tulevat.

Test-Driven Development (TDD)

Test-driven development on testausta korostava ohjelmistokehitysprosessi, jossa kaikki lähtee liikkeelle testien kirjoittamisesta. Heti kun luokan ulkoinen rajapinta on selvillä, kirjoitetaan luokan toiminnalle spesifikaation mukaiset testit. Toimintoa ryhdytään toteuttamaan vasta kun testit ovat olemassa. Vastaavasti kun koodista löytyy virheitä, aloitetaan niiden korjaus kirjoittamalla testi joka osoittaa virheen olemassaolon ja vasta sitten ryhdytään korjaamaan. Mahdollisuus testata virhettä automaattisesti helpottaa korjausprosessia ja myöhemmin testi estää virheen paluun. Test-Driven-Development on kuvattu tarkemmin vaikkapa Wikipediassa

Palaute

Vastaa palautekyselyyn A+:ssa.