SEPA päiväkirja BetaTeam Kauko Huuskonen, 54396W, kauko.huuskonen@tkk.fi Hannu Kankaanpää, 58605L, hkankaan@cc.hut.fi Versio Pvm Tekijä Kuvaus 0.1 16.11.2005 Kauko Huuskonen Template 1.0 20.11.2005 Kauko Huuskonen Johdanto 1.1 21.11.2005 Hannu Kankaanpää Lähdeluettelo, henkilökohtaiset valintaperusteet, johdanto-kappaleen loppuosa, soveltamis-kappaleeseen lisää tekstiä. 1.2 23.11.2005 Kauko Huuskonen Kappale 1.2.2 1.3 24.11.2005 Hannu Kankaanpää Täsmennyksiä kappaleeseen 2. 1.4 3.12.2005 Kauko Huukonen Kokemuksia 1.5 3.12.2005 Hannu Kankaanpää Kokemuksia 1.6 4.12.2005 Hannu Kankaanpää Lisää kokemuksia
SEPA päiväkirja Automaattinen yksikkötestaus Sisältö: 1. Johdanto 1.1. Automaattinen yksikkötestaus 1.2. Henkilökohtaiset valintaperusteet 2. Käytäntöön soveltaminen 3. Kokemukset ja muutokset 3.1. Implementaatio 1 3.2. Implementaatio 2 3.3. Yhteenveto 4. Lähdeluettelo 1. Johdanto 1.1. Automaattinen yksikkötestaus Yksikkö(Unit) on pienin mahdollinen testattava ohjelmistokomponentti (Burnstein 2003). Yksikkö on perinteisesti funktio tai proseduuri, jos asiaa tarkastellaan imperatiivisen ohjelmointikielen kannalta. Oliopohjaisessa kielessä yksiköksi voidaan katsoa sekä metodi että luokka (class). Yksikkötestaamisella varmistetaan, että komponentti toimii määritysten mukaisesti. Menetelmänä se sijoittuu esimerkiksi V-mallissa testaamisen alimmalle tasolle. Testaaminen suoritetaan jokaiselle komponentille erikseen ennenkuin ne integroidaan osaksi suurempaan kokonaisuuteen. Yksikkötestaus voidaan suorittaa ad hoc -hengessä: kun kirjoitetaan lähdekoodiin muutoksia, ohjelma käännetään ja varmistetaan oikean toiminnallisuuden lisääminen. Yksikkötestaus voi olla myös huolellisesti valmisteltua, joka on suositeltavaa. Testitulokset raportoidaan tällöin osaksi yksikön historiaa. Testaamisessa suoritettavat toimet: Suunnitellaan yleinen lähestymistapa yksikkötesteille Suunnitellaan testitapaukset Määritetään relaatiot testeille Valmistellaan yksikkötesteissä käytettävä koodi
Yksikkötestaamisessa käytetyt testitapaukset tulisi suunnitella käyttäen sekä Black box että White box strategioita. Tavoitteena on löytää uhkia määrityksistä, algoritmeista, datasta, ohjauslogiikasta jne. Koska kaikkea ei voi testata, tulisi testata ensisijaisesti niitä ominaisuuksia joissa ongelmia on todennäköisimmin, tai joiden toimivuus on kriittisintä. Yksiköitä tulisi testata sekä tavallisilla syötteillä että virheellisillä, sekä syötteillä jotka tuottavat mahdollisesti epäintuitiivisia tuloksia. Testien tulisi olla mahdollisimman pitkälle automatisoituja, sillä näillä voidaan suorittaa vaivattomasti regressiotestausta bugien korjauksen, uuden toiminnallisuuden lisäämisen ja integroinnin yhteydessä. Nämä testit säilyttävät arvonsa tulevaisuutta ajatellen. Testaaminen yksikkötasolla on elintärkeää sillä tässä vaiheessa bugien jäljittäminen ja korjaaminen tulee halvaksi verrattuna myöhempiin vaiheesiin. Automaattisista yksikkötason testeistä on myös hyötyä yksiköiden toiminnallisuuden ja käyttötapojen kuvaamisessa. Hyvin kirjoitetut testit kertovat täsmällisesti ja luotettavasti miten yksiköt toimivat sekä tavallisissa että poikkeuksellisissa tapauksissa. Näistä voi olla suurta hyötyä korkeamman tason toiminnallisuutta toteutettaessa, erityisesti jos yksikköjen dokumentaatio on puutteellista tai virheellistä. Yksikkötestien suunnitteleminen myös helpottaa itse yksiköiden suunnittelemista modulaarisemmiksi. Jotta yhtä yksikköä voisi testata mahdollisimman eristettynä muusta järjestelmästä, yksikön tulee olla rakennettu irralliseksi komponentiksi. Ilman yksikkötestausta yksiköillä on mahdollisesti vain yksi käyttötarkoitus, minkä takia yksiköitä ei välttämättä suunnitella irroitettavaksi ympäristöstään. Mutta yksikkötesti lisää jokaiselle yksikölle yhden ylimääräisen käyttötarkoituksen, testauksen, joka pitää ottaa suunnittelu- ja kehitysvaiheessa huomioon. Äärimmilleen viety automaattinen yksikkötason testaus voi viedä huomattavasti aikaa. On tyyppillistä esimerkiksi rakentaa pelkästään testauskäyttöön tarkoitettu socket-luokka, joka simuloi verkossa tapahtuvia häiriöitä deterministisesti. Eräät kehittäjät ovat kertoneet projektiensa sisältävän enemmän yksikkötestaukseen liittyvää koodia kuin itse ohjelman toiminnallisuutta parantavaa koodia. Kuitenkin nämä testihullut vakuuttavat että lopputuloksena on luotettavampaa koodia, joka kaiken lisäksi valmistuu nopeammin. Projektissamme automaattinen yksikkötestaus on äärimmäisen tärkeää, sillä joudumme työskentelemään suurissa määrin vanhan koodikannan puitteissa, ja myös sitä muokaten. Yksikkötesteillä voimme varmistaa että vanha koodikanta toimii dokumentaation mukaisesti, ja ettemme muutoksillamme riko sen edelleen tuettua toiminnallisuutta. Ilman yksikkötestien antamaa tietoa vanhojen komponenttien toiminnasta, emme virheiden ilmaantuessa voisi välttämättä ollenkaan arvailla virheen syytä. Koska projektimme käsittelee kriittisiä alueita NAPA-ohjelmistosta, siis tietojen lukemista, kirjoittamista ja poistamista, meidän tulee varmentaa mahdollisimman hyvin ettei koodimme ole viallista. Lisäksi kattavien yksikkötestien avulla voimme myös vakuuttaa asiakkaamme koodimme luotettavuudesta. Aiheesta lukemamme artikkelit on lueteltu lähdeluettelossa.
1.2. Henkilökohtaiset valintaperusteet 1.2.1. Hannu Olen kiinnostunut testivetoisesta kehityksestä (test driven development), mutta koska en omaa hirveästi aiempaa kokemusta edes tavallisesta yksikkötestaamisesta, ajattelin tämän SEPA-aiheen sopivan parhaiten ponnahduslaudaksi testauksen ihmeelliseen maailmaan. Tässä projektissa pääsee testaamaan mm. itse kirjoittamaansa Java-koodia, muiden ryhmäläisten kirjoittamaa koodia, vanhaa Fortan-koodia sekä tietokantaa. Testattavien alueiden kirjo on siis varsin laaja, ja uskoisin oppivani paljon. Luin tätä projektia varten erityisesti mock-olioista (mm. Lähteet [2], [3] ja [4]) sillä ajattelin niitä tarvittavan mm. tietokantayhteyksien testaamisessa. JUnit:n käyttö on myös uutta. 1.2.2. Kauko Olen koko syksyn ajan opiskellut ohjelmistotestaamisen periaatteita ja nähnyt monenlaisia raportointitapoja ja testitapauksia. Kiinnostukseni kohteena projektin alusta lähtien on ollut testaaminen, sen suunnittelu ja toteutus. Projektissamme tulee olemaan paljon testaamista ja laadun varmistamista, joten tulen saamaan arvokasta kokemusta ohjelmiston testaamisesta oikeassa kehitysprojektissa. 2. Käytäntöön soveltaminen Projektissamme yksikkötason testaus on suuressa roolissa, sillä funktionaalisuutta on hajoitettu todella paljon pieniin osiin. Lähdekoodi on kirjoitettu mm. Fortranilla, Javalla ja C:llä. Alkuperäisiä muistinhallinta-funktioita on lukuisia ja joudumme käyttämään näitä siirtäessämme dataa uuteen luomaamme tietokantaan ja hakiessamme tietoa sieltä. Käytämme testaamiseen Javan JUnit-kirjastoa. Projektimme sydän on Javassa, josta voimme kutsua C-funktioita, niiden kautta Fortran-funktioita (NAPA DLL), sekä tehdä kutsuja tietokantaan. Siksi on luonnollista keskittää kaikki testaaminen Javaan, hyödyntäen suosittua JUnit-kirjastoa. Yksikkötesteillä voimme varmistaa että se koodikanta, johon projektimme sisältyy, toimii tarvittavilta osin niin kuin oletamme. Vanhan koodin osalta yksikkö on pienin mahdollinen ulkoisesti testattava osa; Esimerkiksi funktiota, joka vain kirjoittaa muistiin, ei voi testata yksinään. Sen pariksi tarvitaan vielä lukufunktio, jolla testataan että muistista voidaan lukea sinne kirjoitetut tiedot oikein. Konseptuaalisesti tämä kuitenkin vastaa täysin Javan yksikkötestausta, jossa yksikkönä on luokka. Lisäksi varmennamme yksikkötesteillä tietysti oman koodimme toimivuuden, ja tarjoamme samalla asiakkalle esimerkkikoodia siitä kuinka kirjoittamiamme luokkia tulee käyttää. Jos asiakas tai ryhmämme löytää järjestelmästämme vikoja, pyrimme ensin kirjoittamaan testin joka demonstroi vikaa ja vasta sitten korjaamme vian. Näin voimme saada jonkinlaista varmuutta siitä, että onnistuimme korjaamaan vian.
Nimeämme kaikki yksikkötestausluokkamme Test-päätteisiksi. Esim. luokka DmTest testaa luokkaa Dm. Teemme lisäksi yhden testitapauksen, jonka ajamalla saa ajettua kaikki testit automaattisesti. Muokkaamme tarvittaessa koodia helpommin testattavaksi, esimerkiksi käyttämällä suunnittelumallia Kontrollin kääntäminen [6]. Kirjoitamme tarvittaessa mock-olioita simuloimaan testattavan yksikön ulkopuolisia järjestelmän osia deterministisesti. Testejä kirjoittavat Hannu Kankaanpää, joka on projektissa pääasiassa kehitysroolissa, sekä Kauko Huuskonen, jonka roolina on pääasiassa testaus. Testitapauksien kirjoittaminen sijoittuu I1-iteraatiossa sen loppupäähän, ja painottuu myös I2-iteraatiossa loppupuoliskolle. I2-iteraatiossa saatamme kirjoittaa joitain testitapauksia jopa ennen itse toiminnallisuuden kirjoittamista, ja raportoimme kokemuksista. Testien kirjoittamisen jälkeen niitä pyritään ajamaan usein: Kaikki testit ajetaan läpi vähintään viikottain, ja useammin jos ongelmia ilmenee. Testeissä ilmenevät viat raportoidaan välittömästi viallisen koodin kirjoittaneelle kehittäjälle, jonka ensimmäisen prioriteetin tulee olla testissä paljastuneen vian korjaaminen ellei hänellä ole pätevää syytä tehdä jotain muuta osa-aluetta ensin. IMPLEMENTAATIO I Viikolla 47: Yksikkötestaus alkaa. NAPA:n muistinkäsittelyfunktioiden ja tietokannan luku-ominaisuuden testaamista. Viikolla 48: Testit kirjoitus ja poisto-ominaisuuksille. IMPLEMENTAATIO II 3. Kokemukset ja muutokset 3.1. Implementaatio 1 3.1.1. Kauko Projektin ensimmäisessä iteraatiossa aikataulu venyi kehittämisen osalta. Tämä johtui projektin luonteesta: tutkimme tarkkaan mitä kehitämme ja miten. Yksikkötason testitapauksia oli vaikea hahmottaa ja testaaminen viivästyi. Käytönnössä yksiköiden testaaminen vaatii vielä suunnittelua, joten suoritamme yksikkötestausta laajemmin vasta toisessa iteraatiossa. Saimme ensimmäisen iteraation lopussa toteutuksemme käännettävään kuntoon ja ajettua ensimmäiset testit. Automaattinen yksikkötestaus käsitteenä oli projektin alussa vielä hieman hämärän peitossa. Nyt olen tutustunut periaatteisiin tarkemmin teoreettisella tasolla ja odotan saavani käytännön kokemuksia toisen iteraation aikana. 3.1.2. Hannu
Tässä iteraatiossa testaus aloitettiin varsin myöhäisessä vaiheessa, koska implementaation työstäminen testattavaan vaiheeseen vei aikaa. Ajan puutteesta johtuen en ehtinyt toteuttamaan mock-olioita järjestelmälle, ja joistain automaattisista testeistä tuli siten varsin laaja-alaisia. Sain kuitenkin runsaasti ideioita siitä, miten toteutusta voisi muuttaa seuraavassa vaiheessa helpommin testattavaksi. Testaamista olisi pitänyt suunnitella jo ennen implementaation aloittamista, jotta implementaation olisi voinut kirjoittaa samantein oikein. Siis vaikka kirjottaisimmekin kakkositeraatiossa testit vasta loppupuolella, olisi hyvä huomioida testaamisen aiheuttamat vaatimukset jo suunnitteluvaiheessa. Otimme suunnitellusti käyttöön JUnit-kirjaston, ja toteutin jonkinlaiset testit käytännössä kaikille merkittäville Java-luokille (joista osa toimii kutsurajapintoina C- ja Fortrankoodille). TestAll-luokka ajaa kaikki testit yhdellä kertaa. Natiivin koodin testaaminen DLL:n avulla oli suoraviivaista, mutta vaati melkoisesti wrapper-koodia. Koska käytössämme oli vain yksi ympäristö, jolla DLL:n pystyi kääntämään (asiakkaan kannettava), ja DLL:n muuntamisvastuu oli toisella kehittäjällä, testaaminen hidastui kohtuuttomasti. Aina kun bugi löytyi natiivista päästä, piti odotella että toinen kehittäjä luo uuden DLL:n joka korjaa virheen, vaikka virhe olisi ollut hyvin yksinkertainenkin. Jos kukin kehittäjä kirjoittaisi alustavat yksikkötestit itse omalle koodilleen, suurin osa bugeista saataisiin nopeasti poistettua. Koodin kirjoittanut henkilö tietäisi parhaiten, missä viat ovat, ja osaisi korjata ne nopeasti. Toisaalta ulkopuolisten suorittama black box-testaus voi paljastaa bugeja, joita koodin kirjoittanut henkilö ei osaisi kuvitellakaan. Tässä ensimmäisessä iteraatiossa lähes kaikki testaus oli white box-testausta, mutta toivottavasti seuraavassa iteraatiossa on mahdollisuus harjoittaa myös black boxtestausta. Löysin testeillä pari selvää bugia kirjoittamastamme koodista, ja testien muodostama turvaverkko antoi varmuutta koodin muuttelemiselle. Aina ennen CVS commit:ia pystyi testit ajamalla varmistamaan että koodi on jokseenkin toimivassa kunnossa. Testien kirjoittaminen myös pisti miettimään, kuinka irrallisiksi yksiköt pitää saada jotta yksikkötestaus on yksikkötestausta. Voiko yksikössä käyttää Javan LinkedList-luokkaa, vai pitääkö mahdollistaa sen korvaaminen mock-oliolla testaamista varten? Eli sallitaanko yksiköissä staattisina ainoastaan primitiivit int, float jne.? Ja jos LinkedListluokan käyttö hyväksytään, miksei myös itse implementoidut säiliöt, jotka on testattu erillisillä testeillä? Tähän projektiin tämä kysymys liittyy oleellisesti, sillä Napan natiivi koodi nimenomaan tarjoaa eräänlaisen säiliörajapinnan. Sen käyttäminen testauksessa helpottaisi yksikkötestien kirjoittamista, sillä kyseiseen säiliöön tulee kirjoittaa tietoa myös ohjelman normaalissa ajossa, eikä tälle säiliölle siten tarvitsisi kirjoittaa mockoliota testaamista varten. Juuri näin testaus suoritettiin tässä iteraatiossa. Toisaalta testausympäristö ei ole ainut erilainen ympäristö mihin yksikkö voidaan sijoittaa, joten yksikön modulaarisuuteen olisi hyvä tähdätä joka tapauksessa. Jos esimerkiksi Napan natiivit osat muunnettaisiin tulevaisuudessa Javalle, olisi suotavaa että nykyistä tietokantakomponenttia voisi käyttää sellaisenaan. Testauksen toteuttaminen sai
pohtimaan erilaisia lähestymistapoja tämän saavuttamiseksi (esim. välikieli), mutta niiden implementoimiseen ei ollut aikaa tässä iteraatiossa. 3.2. Implementaatio 2 3.3. Yhteenveto 4. Lähdeluettelo 1. JUnit Test Infected: Programmers Love Writing Tests < http://junit.sourceforge.net/doc/testinfected/testing.htm > 2. Approaches to Mocking < http://www.onjava.com/pub/a/onjava/2004/02/11/mocks.html > 3. Kent Beckin wiki; Mock Object < http://c2.com/cgi/wiki?mockobject> 4. Unit testing with mock objects < http://www-128.ibm.com/developerworks/library/j-mocktest.html > 5. A Dozen Ways to Get the Testing Bug in the New Year < http://today.java.net/pub/a/today/2004/01/22/dozenways.html > 6. Design Better Software with the Inversion of Control Pattern < http://www.devx.com/java/article/27583 > 7. Burnstein, Ilene, Practical Software Testing, Springer-Verlag, 2003