(Joskus puhutaan myös komponenttitestauksesta.) Pienin kokonaisuus, joka on järkevä testata erikseen. ● Perinteisesti yksittäinen aliohjelma. ● Olio-ohjelmien.

Esitys aiheesta: "(Joskus puhutaan myös komponenttitestauksesta.) Pienin kokonaisuus, joka on järkevä testata erikseen. ● Perinteisesti yksittäinen aliohjelma. ● Olio-ohjelmien."— Esityksen transkriptio:

1 (Joskus puhutaan myös komponenttitestauksesta.) Pienin kokonaisuus, joka on järkevä testata erikseen. ● Perinteisesti yksittäinen aliohjelma. ● Olio-ohjelmien testauksessa yksiköksi lasketaan usein kokonainen luokka: ● Monet metodit ovat hyvin yksinkertaisia. ● Metodien välillä voi olla vahvoja riippuvuuksia. ● Monet ei-triviaalit metodit voidaan silti testata ensin erikseen. Miksi järjestelmätestaus (JT) tms. ei riitä vaan yksikkötestaustakin (YT) tarvitaan? ● JT ei saa katetuksi yksikköjä kovin hyvin (koskee sekä musta-laatikko- että lasilaatikkonäkökulmaa). ● Mitä laajempaa kokonaisuutta testataan, sitä vaikeampi on löytää ne virheet, joista havaitut häiriöt aiheutuvat. Yksikkö- eli moduulitestaus (1/4)

2 ● Asiakasmoduulin testaaminen yhdessä ennestään testaamatto-mien (siis luultavasti virheellisten) palvelinmoduulien kanssa ei yleensä ole järkevää. ● Mitä varhaisemmassa vaiheessa virheet havaitaan, sitä vähemmän kustannuksia niistä ja niiden korjaamisesta ehtii aiheutua. ● YT on huomattavasti helpommin automatisoitavissa kuin JT. ● Testattava kokonaisuus on pienempi ja yksinkertaisempi. ● Tarkkailtavat häiriöt ovat yksinkertaisempia ja selkeämpiä. Yksikkötestauksen aiheuttamia lisärasitteita: ● Yleensä moduuli ei ole sellaisenaan testattavissa, vaan täytyy rakentaa jonkinlainen testipeti (test bed). ● Testiajurilla (test driver) toteutetaan testitapaukset: annetaan syötteet ja otetaan vastaan tulokset. ● Tynkiä (stubs) tarvitaan usein korvaamaan sellaisia testattavan moduulin tarvitsemia palvelinmoduuleja, joita ei ole vielä toteutettu. Yksikkö- eli moduulitestaus (2/4)

3 Yksinkertaisin tapaus: puhtaasti funktionaalinen aliohjelma: ● Tulos riippuu vain eksplisiittisistä parametreistä (tai muista syötteistä). ● Siis mm. ei muistia eri kutsujen välillä. ● Ei sivuvaikutuksia. Tätä ominaisuutta ei välttämättä voida todentaa staattisesti (ilman testausta)! Yleinen tapaus: ● Syötteiksi on laskettava myös aliohjelman sisäinen muisti sekä kaikki globaalit muuttujat yms., joita aliohjelma voi lukea. ● Tuloksiksi on laskettava myös kaikki sivuvaikutukset (esim. globaalien muuttujien muuttaminen). Tyypillinen tilanne: mahdollisten implisiittisten syötteiden ja tulosteiden joukko on suhteellisen pieni ja tunnettu. ● Olio-ohjelmointi: metodin käytettävissä aina kohdeolion (nykyolion) atribuutit (ilmentymämuuttujat). Yksikkö- eli moduulitestaus (3/4)

4 Aliohjelman yksi (melko yleinen) ääritilanne: ei mitään palautettavaa tulosta, vaan pelkästään sivuvaikutuksia moduulin tai olion sisäiseen tilaan. ● Ainakin mustalaatikkotestauksessa jokaisen testitapauksen täytyy sisältää myös jokin tuloksen palauttavan aliohjelman kutsu. Käänteinen ääritilanne: ei mitään eksplisiittisiä syötteitä, vaan tulos riippuu vain moduulin tai olion sisäisestä tilasta. ● Ainakin mustalaatikkotestauksessa testitapauksen täytyy sisältää myös yksi tai useampi tilaa muuttavan aliohjelman kutsu. Yksikkö- eli moduulitestaus (4/4)