AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7
Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan revision päiväys (päiväys) Revision Numero Revision Päiväys Yhteenveto muutoksista Muutokset merkitty 0.1 21.10.04 Ensimmäinen versio Ei 0.2 30.10.04 Pieniä lisäyksiä käyttöönottoon ja kuvaukseen Ei 0.3 29.11.04 I1-vaiheen muutokset ja kokemukset kirjattu Ei Hyväksyjät Tämä dokumentti vaatii seuraavien henkilöiden hyväksymiset Nimi Petri Kalsi Heikki Salminen Tehtävä Jakelu Tämä dokumentti jaetaan seuraaville henkilöille Nimi Projektiryhmä Seppo Sahi Tehtävä Mentor Aihe: PK&HS Sivu 2 / 7
Sisällysluettelo 1. Esittely...4 1.1 Tarkoitus...4 1.2 Viittaukset...4 1.3 Menetelmän kuvaus...4 2. Käyttöönotto...5 3. Kokemukset ja muutokset...6 3.1 PP-vaihe...6 3.2 I1-vaihe...6 3.3 I2-vaihe...6 3.4 FD-vaihe...6 3.5 Yhteenveto...7 Aihe: PK&HS Sivu 3 / 7
1. Esittely 1.1 Tarkoitus Tämän dokumentin tarkoitus on kuvata ElectricSeven-ryhmän kahden jäsenen käyttämää SEPAmenetelmää automaattisia yksikkötestejä. Menetelmä esitellään ja perustellaan luvussa 1. Luku 2 sisältää suunnitelmat menetelmän käyttöönotolle. Lukuun 3 kirjataan kokemuksia ja havaintoja menetelmän hyödyistä ja sopivuudesta projektin tarpeisiin. 1.2 Viittaukset Muut käytetyt testaus- ja laadunvarmistusmenetelmät on kuvattu testaussuunnitelmassa. 1.3 Menetelmän kuvaus Valitsemamme SEPA-aihe on automaattiset yksikkötestit. Aiheen valinta oli helppo, sillä yksi asiakkaan järjestelmälle asettamista vaatimuksista oli automaattisten yksikkötestien käyttö. Yksikkötestaus soveltuu myös aiheena hyvin meille, testausvastaavan (Petri Kalsi) ja laatuvastaavan (Heikki Salminen) rooleissa toimiville ryhmän jäsenille. Kurssin T-76.613 Ohjelmistojen testaus ja laadunvarmistus suoritus samanaikaisesti projektin ohella antaa hyvät pohjat yksikkötestauksen suunnittelulle ja toteutukselle. Yksikkötestit integroidaan build-skripteihin, ja ne suoritetaan aina uuden version kääntämisen yhteydessä. Yksikkötestaus ei aiota suorittaa koko järjestelmälle, vaan ainoastaan tärkeimmille, matalan tason toiminnallisuudesta vastaaville luokille, ja yleisesti sille osalle johon yksikkötestaus parhaiten soveltuu. Yksikkötestaukseen osallistuvat kaikki ohjelmoijat, jotka implementoivat yksikkötestauksen piiriin kuuluvia luokkia. Testiluokkien ohjelmointi tehdään pääosin I1 ja I2-vaiheissa. Testeistä pyritään tekemään mahdollisimman mukautuvia, jotta samoja testejä voidaan ajaa vähin muutoksin koko projektin ajan. Aihe: PK&HS Sivu 4 / 7
2. Käyttöönotto Yksikkötestaus aloitetaan heti I1-vaiheessa samanaikaisesti ohjelmoinnin aloituksen kanssa. Yksikkötestaukseen kuuluvien luokkien toteutuksesta vastaavien ohjelmoijien vastuulla on myös toiminnallisuutta testaavien testiluokkien ohjelmointi. Yksikkötestausta jatketaan niin kauan kuin testattavien luokkien kehitys jatkuu. Yksikkötestit on ajettava aina, kun testattavaan luokkaan tehdään jotain muutoksia. Käytännössä tämä tapahtuu integroimalla yksikkötestit ajettavaksi automaattisesti tehtävän buildin yhteydessä. Testiluokkien toteutukseen käytetään JUnit-frameworkia. Testaukseen käytetty aika on rajallista, joten nyrkkisääntönä pidetään, että yksikkötestien kirjoittamiseen kulutetaan 10 20 % siitä ajasta, mitä vastaavan toiminnallisuuden implementointiin on arvioitu kulutettavaksi. Tämän takia testaus pyritään keskittämään kussakin luokassa tärkeimpiin ominaisuuksiin. Mikäli luokassa on yksi tärkeä ulkoa päin kutsuttava metodi, joka itse käyttää suurta osaa luokan muista metodeista, on testaus järkevää keskittää kyseiseen metodiin. Jos luokkaa joudutaan myöhemmin muuttamaan esimerkiksi löydetyn vian vuoksi, testitapausten lisäämiseen ja parantamiseen käytetään taas 20 % toiminnallisuuden korjaamiseen käytetystä ajasta. Testiluokat nimetään periaatteella <testattava_luokka>test.java, jotta testiluokat olisivat helposti erotettavissa ja integroitavissa build-skripteihin. Testimetodit nimetään mahdollisimman kuvaavasti, tyyliin test<testattava_asia>(), esim. testaddissuetoincrementbacklog(). Kaikki ryhmän jäsenet ovat suorittaneet kurssin T-76.613, tai suorittavat sitä parhaillaan projektin ohella, joten erillistä koulutusta menetelmän käyttöönotolle ei tarvita. Yksikkötestaus painottuu luotuihin Enterprise Java Bean -luokkiin, jotka muodostavat järjestelmän matalan tason rajapinnan Hibernate-tietokantakerroksen päälle. Jokaisen EJB-luokan tärkeimpiä metodeja pyritään testaamaan vähintään kerran jossain testitapauksessa. Täydelliseen kattavuuteen ei pyritä vielä I1-vaiheessa rajallisen tuntimäärän takia. I2-vaiheessa jatketaan yksikkötestien kehittämistä kattavuuden parantamiseksi, ja automaattista ajamista buildien yhteydessä. Aihe: PK&HS Sivu 5 / 7
3. Kokemukset ja muutokset 3.1 PP-vaihe Yksikkötestausta ei oteta käyttöön PP-vaiheessa. 3.2 I1-vaihe EJB-luokkien implementointi lykkääntyi myöhäiseen vaiheeseen I1-iteraatiota, joten yksikkötestausta ei ehditty toteuttaa suunnitellussa laajuudessa. Testejä toteutettiin esimerkin omaisesti muutamille luokille (CycleManager, ProductManager, BacklogItemManager), jotta muiden ryhmän jäsenten olisi helpompaa ryhtyä kirjoittamaan testejä. Lopuille EJB-luokille kirjoitetaan yksikkötestejä joulukuun aikana ennen I2- vaiheen alkua. Testit ehdittiin integroida ant-työkalun avulla automaattiseen build-järjestelmään nimeltä CruiseControl. Testit ja uusi build ajetaan aina, kun järjestelmä havaitsee muutoksia cvs:n hakemistopuussa. Testien tulokset ovat luettavissa erillisellä www-sivulla <http://bannedwagon.net:8080/cruisecontrol/buildresults/>, josta löytyvät myös aiempien buildien tulokset. Niiltä osin kuin testejä ehdittiin kirjoittaa, yksikkötestaus havaittiin käteväksi tavaksi testata matalan tason rajapintaa. Testit paljastivat useita virheitä, jotka ehdittiin korjata I1-vaiheen lopussa. Automaattisen testausympäristön pystyttäminen osoittautui yllättävillä tavoilla hankalaksi. Tietokantaan ladattavan testidatan hallinta ja kantaan lataaminen aiheutti vaikeuksia, koska osa testeistä muokkasi samaa dataa tai sotki kantaa niin, että myös tietokannan tyhjentäminen testauskierrosten välillä täytyi automatisoida. Suuri osa yksikkötesteistä on sivuvaikutuksellisia, joten aikaisemmat testitapaukset vaikuttavat järjestelmän tilaan ja testien suoritusjärjestyksellä on suuri merkitys. Päätimme tehdä yksittäisistä testitapauksista hieman tavanomaista laajempia. Yksi testitapaus testaa yhden luokan useampaa metodia tai toimintoa, jotta sivuvaikutusten määrä saadaan minimoitua. Yksi testitapaus suorittaa muutaman peräkkäisen toiminnon sarjan samalle datalle. Näin datan ja suoritusjärjestyksen hallinta helpottui ja testitapausten ylläpitäminen on selkeämpää. Järjestelmän arkkitehtuuri asetti rajoitteita yksikkötestien muotoilemiselle. Käytännössä yhtä EJB-luokkaa testaavan testijoukon täytyi käyttää myös muutamaa (1-4) muuta EJB:tä testeille sopivan alkutilan aikaansaamiseen ja parametrien muodostamiseen. Tästä ei ole toistaiseksi aiheutunut ongelmia. Tämän takia testijoukot (JUnitin TestSuitet) kannattaa suorittaa tietyssä järjestyksessä, jotta vian löytäisi oikeaa luokkaa testaava testi. Näin saadaan siistein virheilmoituslista. Nopeasti hyvän testikattavuuden saavuttamiseksi implementoitiin jo alkuvaiheessa testit luokkaa BacklogItemManager varten. Se käyttää suoraan tai epäsuoraan noin puolta järjestelmän kaikista EJBluokista. Muut ryhmämme jäsenet eivät ole vielä päässeet kunnolla mukaan yksikkötestien kirjoittamiseen, mutta toisaalta implementaatiokoodiakin on hieman suunniteltua vähemmän. Mielestämme testien nykyinen kattavuus on kohtalaisen hyvä. 3.3 I2-vaihe 3.4 FD-vaihe Aihe: PK&HS Sivu 6 / 7
3.5 Yhteenveto Aihe: PK&HS Sivu 7 / 7