Yksikkötestaaminen
Yksikkötestaaminen (engl. unit testing) on tietokoneohjelman testaamisen ja laadunvarmistuksen menetelmä, jossa lähdekoodin osat testataan yhdessä tai erikseen.[1] Yksikkötestaamisessa käytetään pienintä palaa testattavasta ohjelmasta ja se eroaa koko ohjelman testaamisesta yhtenä kokonaisuutena. Yksikkötestaamisessa testattava pala eristetään muusta ohjelmasta ja tarkistetaan toimiiko se kuten sen odotetaan toimivan.[2]
Yksikkö tarkoittaa sovelluksen osaa. Yleensä yksikkö on yksittäinen toiminto, mutta esimerkiksi olio-ohjelmoinnissa yksikkö voi olla kokonainen luokka. Testeistä saadaan kattavia rakentamalla niitä ensin pienimmille testattaville yksiköille ja sen jälkeen niiden välisille yhteyksille. Ongelmien kartoittamiseksi jokainen testitapaus tulee testata erikseen. [3]
Yksikkötestauksen tavoitteena on eristää ohjelman jokainen osa ja osoittaa, että yksittäiset osat toimivat oikein. Yksikkötesti tarjoaa tiukan sopimuksen, joka koodinpalan on täytettävä. Yksikkötestaus löytää ongelmat kehityssyklin alkuvaiheessa. Vikoja voi ilmetä ohjelmoijan toteutuksessa ja yksikön määrityksessä. Testisarjan kirjoittaminen pakottaa miettimään syötteitä, lähtöjä ja virheolosuhteita, joiden avulla yksikön käyttäytyminen saadaan määriteltyä paremmin. Yksikkötestauksen kustannukset ovat huomattavasti alhaisemmat, kuin näiden virheiden löytäminen ohjelmistokehityksen loppuvaiheessa. [4][5][6]
Yksikkötestaaminen tyypillisesti voidaan suorittaa automatisoidusti, mutta myös manuaalisesti suorittaminen on mahdollista.
Ohjelman eri osat voidaan testin ajaksi korvata yksinkertaistetuilla korvikkeilla.[7] Korvattavat osat eivät kuulu varsinaiseen testattavaan yksikköön.
Yksikkötestaamisen lisäksi voidaan tehdä integraatiotestaaminen, jossa eri yksiköt testataan yhtenäisenä kokonaisuutena.
Standardit, kuten IEC 61508, voivat vaatia ohjelman yksikkötestaamista.
Haittapuolet ja rajoitteet[muokkaa | muokkaa wikitekstiä]
Testien kehittäminen voi vaatia paljon aikaa: jokaista Java-koodiriviä kohden tarvitaan keskimäärin 3–5 JUnit-koodiriviä riittävän kattavuuden saavuttamiseen.Tämä voi johtaa siihen, että investointi yksikkötestaukseen ei ole vaivan arvoista. Usein jos ohjelma on hyvin buginen, myös yksikkötestin koodi toimii kehnosti.[8] Kuitenkin testien kirjoittamista ja ylläpitoa voidaan nopeuttaa parametroiduilla testeillä. Ne mahdollistavat yhden testin suorittamisen useita kertoja eri tulosarjoilla, joka vähentää testikoodin päällekkäisyyttä. Tavalliset yksikkötestit on suljettuja menetelmiä ja testaavat muutamia ehtoja, kun taas parametroidut testit testaavat minkä tahansa parametrin. [9][10]
Yksikkötestauksessakaan ei voida havaita jokaista ohjelman virhettä, koska se ei voi arvioida jokaista suorituspolkua muissa kuin triviaalisimmissa ohjelmissa. Tätä ongelmaa ei voida ratkaista. Tämän lisäksi yksikkötestaus määritelman mukaan testaa vain yksiköiden toimivuutta, joka johtaa siihen, ettei integrointivirheitä tai laajempia järjestelmätason virheitä huomata. Järjestelmätason virheiksi voidaan määritellä useissa yksiköissä suoritettuja toimintoja tai ei-toiminnallisia testialueita, kuten suorituskykyä. Tämän takia yksikkötestaus tulee tehdä muiden ohjelmistojen testaustoimintojen yhteydessä, jotta testauksesta saadaan tarpeeksi kattava. Yksikkötestaus ei vastaa integraatiotestausta, jolloin integrointi oheislaitteiden kanssa tulee sisällyttää itse integraatiotestaukseen.[11][12]
Yksi haaste on yksikkötestien kirjoittamiseen liittyvä, realististen ja hyödyllisten testien asettamisen vaikeus. Asiaankuuluvat alkuehdot tulee luoda testiä tehdessä, jotta testattava sovelluksen osa käyttäytyy kuin osa koko järjestelmää. Jos alkuehdot puuttuvat tai ne eivät ole asetettu oikein, testi ei käytä koodia realistisessa kontekstissa joka heikentää testin arvoa ja tarkkuutta.[13]
Jotta yksikkötestauksesta hyödytään, tulee pitää kirjaa suoritetuista testeistä ja kaikista muutoksista, jotka on tehty ohjelmiston yksikön lähdekoodiin. Versionhallintajärjestelmän käyttö on välttämätöntä. Jos myöhempi versio ei läpäise tiettyä testiä, jonka sen aiempi versio oli läpäissyt, löytyy versionhallinnasta luettelo lähdekoodin muutoksista, joita on tehty yksikössä tämän ajankohdan jälkeen. Tällöin voidaan tarkastella missä kohtaa virhe on sattunut. Tämän lisäksi on tärkeä ottaa käyttöön kestävä prosessi, joka varmistaa, että testitapausten epäonnistumiset tarkistetaan säännöllisesti ja niihin puututaan välittömästi. Jos tämä prosessi unohdetaan, testien tehokkuus heikkenee ja positiivisten tulosten määrä vähenee.[14]
Sulautetun järjestelmäohjelmiston yksikkötestaus on ainutlaatuinen haaste yksikkötestauksessa. Koska tämä ohjelmisto kehitetään eri alustalle kuin, millä se lopulta ajetaan, testiohjelmaa ei voida suorittaa kovinkaan helposti ohjelman käyttöympäristössä kuten vaikka työpöytäohjelmien kanssa.[15]
Testaamisen työkalut[muokkaa | muokkaa wikitekstiä]
Yksikkötestauskehykset ovat useimmiten kolmannen osapuolen tuotteita, joita ei jaeta osana kääntäjäpakettia. Ne auttavat yksinkertaistamaan yksikkötestausprosessia, koska ne on kehitetty useille eri kielille.
Yksikkötestaamiseen on useita alustoja kuten JUnit, NUnit ja KUnit.
Kielitason yksikkötestauksen tuki[muokkaa | muokkaa wikitekstiä]
Jotkut ohjelmointikielet tukevat suoraan yksikkötestausta. Tämä tarkoittaa, että niiden kielioppi mahdollistaa yksikkötestien suoran ilmoittamisen ilman kirjaston tuontia.
Kielet, joissa on sisäänrakennettu yksikkötestaustuki:
Joillakin kielillä ei ole sisäänrakennettua yksikkötestaustukea, mutta niillä on perustettu yksikkötestauskirjastot tai -kehykset. Näitä kieliä ovat:
|
|
|
Lähteet[muokkaa | muokkaa wikitekstiä]
- ↑ Unit Testing softwaretestingfundamentals.com. Viitattu 27.9.2017.
- ↑ Unit Testing msdn.microsoft.com. Arkistoitu . Viitattu 27.9.2017.
- ↑ Hamill Paul: Unit Test Frameworks: Tools for High-Quality Software Development. O'Reilly Media, 2004.
- ↑ Boehm Barry W & Papaccio Philip N: Understanding and Controlling Software Costs. , 1988.
- ↑ Archiveddocs: Test Early and Often docs.microsoft.com. Viitattu 10.8.2022. (englanniksi)
- ↑ Prove It Works: Using the Unit Test Framework for Software Testing and Validation www.ni.com. Viitattu 10.8.2022. (englanniksi)
- ↑ Fowler, Martin: Mocks Aren't Stubs martinfowler.com. Viitattu 27.9.2017.
- ↑ Bob Cramblitt: Alberto Savoia sings the praises of software testing (Archive.org) searchsoftwarequality.techtarget.com. 20.9.2007. Arkistoitu . Viitattu 10.8.2019. (englanniksi)
- ↑ Theories · junit-team/junit4 Wiki GitHub. Viitattu 10.8.2022. (englanniksi)
- ↑ Parameterized tests · junit-team/junit4 Wiki GitHub. Viitattu 10.8.2022. (englanniksi)
- ↑ Cramblitt Bob: Alberto Savoia sings the praises of software testing. , 2007.
- ↑ Brooks Frederick J: The Mythical Man-Month, s. 64. , 1995.
- ↑ Kolawa Adam: Unit testing best practices. , 2009.
- ↑ daVeiga Nada: Change code Without Fear: Utilize a regression safety net. , 2008.
- ↑ Kucharski Marek: Making Unit Testing Practical for Embedded Development. , 2011.