Automaattinen yksikkötestaus

Transkriptio

1 Teknillinen Korkeakoulu T Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä Muutokset Vesa Salento Suunnitelma yksikkötestauksen toteuttamisesta projektissa Vesa Salento Lisätty loppupäätelmät.

2 Sisällysluettelo 1 Johdanto Käyttö projektissa Ajatus Edut Haitat Tavoitteet Tulokset Arvioimisperusteet Mittarit Yhteenveto... 4

3 1 Johdanto Automaattisella yksikkötestauksella tarkoitetaan testausta, jossa yleensä samalla ohjelmointikielellä tehdään testitapauksia kuin millä itse testattava ohjelma on myös toteutettu. Testit tehdään sellaisiksi, että ne voidaan koska tahansa ajaa automaattisesti uudelleen ja ajon lopputuloksesta saadaan raportti, joka kertoo mitkä testit menivät läpi ja mitkä epäonnistuivat. Yksikkötestaus tarkoittaa pääasiassa hyvin pienten yksityiskohtien testausta, jossa testaus kohdistuu pääosin yhden olion tai luokan yhteen metodiin tai funktioon. Tarkoituksena ei ole testata koko järjestelmää vaan vain pienten osien toimintaa. Testit on tapana yleensä kirjoittaa joko yhdessä itse toiminnallisuuden toteutuksen kanssa tai sitten ne voidaan myös kirjoittaa jälkikäteen, mutta tehokkainta olisi kirjoittaa ne yhdessä toteutuksen kanssa. 2 Käyttö projektissa Automaattista yksikkötestausta tullaan käyttämään tässä projektissa. Pääpaino tällä on tutustuttaa koko ryhmä testaustapaan ja kerätä ryhmän jäsenten mielipiteitä ja arvioita toimintatavan toimivuudesta kuin että saada täysin kattava testikokoelma projektille. 2.1 Ajatus Yksikkötestauksen idea tulee pääosin siitä, että sen avulla voidaan toteutuksen aikana luoda testejä, jotka eräällä tavalla todistavat ohjelman toimivan oikealla tavalla. Mikäli toiminnallisuutta myöhemmin muutetaan tai laajennetaan niin ajamalla testit uudelleen voidaan havaita, että onko aiempaan toimivaan ohjelmakoodiin ilmestynyt virheitä, jotka aiheuttaisivat testien ajon epäonnistumisen. Testit muodostavat siis eräänlaisen diagnostiikka keinon, jolla voidaan varmistua järjestelmän toimivuudesta. Olettaen tietysti, että testit ovat kattavia niin testien ajamisella voidaan saada tieto järjestelmän kyvystä toimia oikealla tavalla. Todistus ei ole tietysti täysin varma, mutta on sentään parempi kuin jos ei olisi mitään keinoa arvioida toimivuutta. 2.2 Edut Yksikkötestauksen edut tulevat parhaiten esille siitä, että sen avulla voidaan kirjoittaa ohjelmakoodia, mikä toimii varmemmin ja missä on vähemmän bugeja kuin tavalliseen tapaan kirjoitetussa koodissa. Se ei tietysti mahdollista täysin virheettömän ohjelman kirjoittamista, mutta yleisesti kaikki testaaminen vähentää virheiden määriä. Toinen selkeä etu yksikkötestauksesta on se, että mikäli testit kirjoitetaan yhdessä itse toteutuksen kanssa niin tällöin testejä kirjoittaessa ohjelman rajapinnat tulevat tehtyä paljon selkeämmin. Tämä johtuu siitä, että testeistä käsin pitää käyttää toiminnallisuutta samalla tavoin kuin muut ohjelman osat joutuvat sitä käyttämään ja rajapinnan ollessa huono se on helppo korjata tässä vaiheessa kun sitä ei käytetä kymmenistä muista paikoista. Hyötyä tulee myös siitä, että kun testit on kerran tehty automaattisesti ajettaviksi niin niitä on helppo ajaa yhä uudelleen ja uudelleen. Normaalisti ohjelmoijat eivät paljon ehdi tai kykene testaamaan vanhojen ohjelmalohkojen toiminnallisuutta kun he lisäävät uutta 1

4 toiminnallisuutta ja siksi välillä aiemmin toimiva ohjelma voi yllättäen lakata toimimasta samalla tavalla uuden version myötä. Jos kuitenkin on olemassa yksikkötestejä, jotka testaavat toiminnallisuutta niin uudet versiot eivät niin helpolla voi rikkoa toiminnallisuutta kenenkään sitä huomaamatta. 2.3 Haitat Suurin ongelma yksikkötestauksen automatisoinnissa on siinä, että testien tekemiseen menee hyvin paljon aikaa ja tätä ei välttämättä sallita projekteissa, joissa aikataulu on tiukka. Osittain ongelma johtuu siitä, että tapa on melko uusi ja projektinhallinnasta vastaavilla ei ole käsitystä mitä hyötyä tästä testauksesta on pidemmällä aikavälillä. Nykypäivänä kun ohjelmia yritetään tehdä mahdollisimman tehokkaasti niin toimivan järjestelmän rakentaminen ei ole yhtä tärkeää kuin sen saaminen asiakkaalle mahdollisimman nopeasti ja mahdollisimman vähällä työmäärällä. On myös tietysti mahdollista, että testejä tehdään liikaa ja myös sellaiseen koodiin, jonka toimivuus tulee testattua muulla tavalla ja näin testeihin käytetystä ajasta ei olisi siinä mielessä ollenkaan hyötyä. 2.4 Tavoitteet Tämän projektin puitteissa yksikkötestauksen tavoitteet ovat seuraavat: ryhmän jäsenet saavat kuvan siitä mitä yksikkötestaus on sekä minkälainen työ testien tekeminen on ryhmän jäsenet ymmärtävät testauksen tarpeellisuuden, mutta myös kykenevät hahmottamaan tilanteet, joissa testaus ei välttämättä olisi tarpeellista kaikki ryhmän jäsenet tekevät itse jonkin verran yksikkötestejä lopputuotteelle saadaan aikaiseksi kokoelma yksikkötestejä, jotka aina suoritetaan automaattisesti jokaista julkaisuversiota kohden Tavoitteisiin on tarkoitus päästä sillä, että jokainen ryhmän jäsen saa joko itse valita ohjelmakoodin, jolle hän kirjoittaa yksikkötestejä tai sitten hänelle osoitetaan koodi jolle testit kirjoitetaan. Tämä lähestymistapa siksi, että tavan ymmärtää niin paljon nopeammin kun itse pääsee sitä käyttämään, ja toisaalta tunnin parin käyttäminen testien kirjoittamiseen ei ole liian suuri sijoitus koko projektin aikataulun puitteissa. Tarkoituksena olisi, että testejä kirjoitettaisiin pääosin siihen koodiin, jonka henkilö itse on toteuttanut, mutta tämä on vain suositus ja siksi tässä annetaan vapaampi valinta henkilöille itselleen. Tämän lisäksi automaattisesta yksikkötestauksesta vastaava henkilö kirjoittaa projektille riittävästi testejä, että järjestelmän perustoiminnallisuus voidaan testata testit ajamalla. Tarkoituksena tällä ei ole hakea ymmärrystä yksikkötestauksesta vaan enemmänkin vähentää järjestelmässä olevia bugeja ja varmentaa järjestelmän toimintaa. 3 Tulokset Tuloksia arvioidaan projektin loppupuolella sen jälkeen kun kaikki ryhmän jäsenet ovat kirjoittaneet testejä ja he voivat siten kommentoida testauskäytäntöä. Tällöin myös voidaan nähdä paremmin, että ovatko testit auttaneet virheiden paikallistamisessa tai sen 2

5 varmistamisessa, että järjestelmä ei ole hajonnut uutta toiminnallisuutta lisättäessä. 3.1 Arvioimisperusteet Testauksen onnistumisen arviointi tulee perustumaan käyttäjien antamaan palautteeseen toimintatavasta projektin loppupuolella. 3.2 Mittarit Arvioinnin mittarina käytettiin kyselyä, johon ryhmän muut jäsenet vastasivat sähköpostilla. Joihinkin vastauksiin pyydettiin vapaampaa vastausta, mutta pääosin kysymykset olivat monivalintakysymyksiä. Käytetyt kysymykset ja vastausten hajonta on nähtävillä seuraavasta taulukosta: Kysymys Kyllä Ei EOS 1. Oletko aiemmin tehnyt yksikkötestejä muissa projekteissa? Oliko käsite yksikkötestaus tuttu ennen projektin alkua? Paraniko käsityksesi yksikkötestauksessa projektin aikana? Olisitko kaivannut selkeämpää ohjausta yksikkötestien tekemiseen kuin mitä nyt oli saatavilla? 5. Teitkö omasta mielestäsi riittävästi testejä, jotta sait hyvän käsityksen mitä niiden tekeminen vaatii? 6. Oliko sinulla testejä tehdessäsi ylivoimaisia vaikeuksia junitympäristön, API:n tms. kanssa? Mikäli oli niin tarkenna missä. 7. Auttoiko testien kirjoittaminen sinua huomaamaan yhtään bugia tässä projektissa? 8. Korjasitko yhtään bugia järjestelmässä tämän projektin aikana joka olisi huomattu yksikkötestejä ajamalla? 9. Tuliko yksikkötestejä tehdessä yhtään mieli parannella testattavien luokkien rajapintoja tai muuten refaktoroida koodia? a. Kuinka monta testiä kirjoitit kaikkiaan järjestelmään? 0 5 b. Mikäli kirjoitit testejä sekä itse kirjoittamaasi sekä toisten kirjoittaman koodin testaamiseen niin huomasitko mitään eroa näissä tapauksissa? Ei tapahtunut c. Kuinka kauan käytit keskimäärin aikaa testien kirjoittamiseen? 0 3 tuntia I. Oliko yksikkötesteistä mielestäsi hyötyä ja jos oli niin mitä? Mikäli et nähnyt niistä olevan hyötyä niin arvioi miksi näin oli. II. Olisiko sinun mielestäsi yksikkötestejä pitänyt olla enemmän ja jos olisi niin miksi? III. Olisitko itse tehnyt yksikkötestausta eri tavalla? Mikäli olisit niin selitä miten. IV. Oliko mielestäsi yksikkötestauksesta tässä projektissa mitään hyötyä vai oliko se pelkkää ajanhukkaa? Perustele. 3

6 4 Yhteenveto Ryhmän jäsenten vastausten perusteella nähdään, että yksikkötestauksella ei tässä projektissa hyödytty hirveästi bugien löytämisen suhteen. Tämä ei ole ollenkaan yllättävää, sillä yksikkötestaus on parhaimmillaan diagnostinen työkalu, jolla voidaan myöhemmin varmistaa perustoiminnallisuuden toimivan muutosten jälkeen. Kuitenkin moni ryhmän jäsen ei ollut aiemmin tehnyt yksikkötestausta ja heidän käsityksensä parani projektin aikana mikä olikin yksi tavoitteista. Kaiken kaikkiaan palautteen mukaan tuli selkeä kuva siitä, että hyödyt yksikkötestauksesta jäi melko vähäiseksi, mutta ei niihin käytetty kuitenkaan niin hirveästi aikaa, että tätä voitaisiin pitää täysin turhana. Alkuperäisistä tavoitteista saavutettiin kaikki muut, mutta täysin kattavaa yksikkötestien kokoelmaa ei saatu aikaiseksi projektille. Tämä oli osittain oletettavissa, sillä testien tekemiseen olisi kulunut huomattavasti enemmän aikaa kuin mitä projektin puitteissa oli mahdollista käyttää. 4