SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant

Transkriptio

1 AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7

2 Dokumenttihistoria Revisiohistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä Ensimmäinen versio Petri Kalsi Pieniä lisäyksiä käyttöönottoon ja kuvaukseen Heikki Salminen I1-vaiheen muutokset ja kokemukset kirjattu Petri Kalsi Dokumentin rakennetta muutettu Esa Mommo I2-vaiheen kokemukset kirjattu Heikki Salminen 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

3 Sisällysluettelo 1. Esittely Tarkoitus Viittaukset Menetelmän kuvaus Käyttöönotto Kokemukset ja muutokset PP-vaihe I1-vaihe I2-vaihe FD-vaihe Yhteenveto...7 Aihe: PK&HS Sivu 3 / 7

4 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 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

5 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 % 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 , 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

6 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 < 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 Tässä vaiheessa näyttää selvältä, että alkuperäinen suunnitelma yksikkötestien kirjoittamisesta ei olisi voinut toimia näin hajanaisessa ja löyhästi aikataulutetussa projektissa. Jos yksikkötestejä halutaan kirjoittaa kattava määrä, se olisi pitänyt aikatauluttaa I2- ja FD-vaiheien alkuun. Vaiheen lopussa aikataulu on väistämättä niin sekava, että yksikkötestit jäävät tekemättä. Aihe: PK&HS Sivu 6 / 7

7 Tämän lisäksi joulukuuksi suunniteltu siistimis-, dokumentointi- ja yksikkötestausvaihe epäonnistui tai ainakin jäi suunniteltua suppeammaksi. Sen aikana saatiin ainoastaan yksi uusi luokka (UserManager) yksikkötestien piiriin. Lisäksi vaiheen aikana saatiin toteutettua pohjaluokka yksikkötestien kirjoittamiseen (DefaultBeanTestCase), mikä on sinänsä merkittävä parannus, mutta ei lisää testien kattavuutta. I1-vaiheessa toteutettuja EJB-luokkia on muutettu I2-vaiheessa jonkin verran muuttuneiden vaatimusten takia. Lisäksi niihin on tehty merkittävä määrä uusia toimintoja. Olemassaolevia yksikkötestitapauksia ajetaan edelleen säännöllisesti CruiseControllin avulla, mutta ne eivät ole löytäneet uusia virheitä. Yksikkötestien kattavuus on I2-vaiheen aikana hieman huonontunut. Kaikenkaikkiaan ohjelmoimiseen on käytetty tähän mennessä noin 300 tuntia. Jos alkuperäisestä tavoitteesta (10-20 % ohjelmointiajasta yksikkötestien kirjoittamiseen) pidettäisiin kiinni, yksikkötestejä pitäisi kirjoittaa tuntia. Yksikkötesteihin käytettyä aikaa ei ole erikseen seurattu, mutta alkuperäisestä tavoitteesta ollaan kuitenkin tällä hetkellä niin kaukana, että sen saavuttaminen tuntuu hyvin epätodennäköiseltä. Jos samaa sovelletaan ainoastaan yksikkötestauksen piiriin otettuihin komponentteihin (EJB-luokat), tavoite on jotakuinkin savutettu. EJB-luokkiin on kulunut suuruusluokkaa kolmannes ohjelmointiajasta, joten yksikkötesteihin pitäisi käyttää suuruusluokkaa 15 tuntia, mikä todennäköisesti vastaa aika hyvin tämänhetkistä todellisuutta. Lisäksi kattavien automaattisten yksikkötestien kirjoittaminen osoittautui vielä oletettuakin työläämmäksi. Suunniteltu % ei selvästikään ole jatkokehitettäväksi tarkoitetulle ohjelmistolle riittävä määrä. Tähän ei kuitenkaan tässä projektissa ehditä enää reagoida. Emme myöskään uskalla esittää arvausta siitä, mikä olisi riittävä määrä. Koska nykyinen yksikkötestikattavuus on huonompi kuin mitä asiakas haluaa, yksikkötestejä on tarkoitus kirjoittaa huomattava määrä lisää FD-vaiheen alussa. Jo alkuperäisessä suunnitelmassa oli varattu FDvaiheen alusta runsaasti aikaa testaamiseen. Osa tästä tullaan käyttämään yksikkötesteihin. Lisäksi FDvaiheen aikana on tarvoitus arvioida automaattisten yksikkötestien kattavuus ainakin summittaisesti. 3.4 FD-vaihe 3.5 Yhteenveto Aihe: PK&HS Sivu 7 / 7