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 tehdään usein automatisoidusti, mutta myös manuaalinen testaus on mahdollinen.
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, saattavat vaatia ohjelman yksikkötestaamista.
Hyödyt muokkaa
Yksikkötestauksella löydetään usein ongelmia jo kehityssyklin varhaisessa vaiheessa. Näitä ovat sekä ohjelmiston kehittäjän tekemät virheet toteutuksessa että yksikön määrittelyssä olevat puutteet tai puuttuvat osat. Perusteellisten testien kirjoittamisprosessi pakottaa ohjelmoijan pohtimaan syötteitä, tulosteita ja virhetilanteita ja siten määrittelemään yksikön halutun käyttäytymisen tarkemmin. Virheiden löytyminen projektin alkuvaiheessa on taloudellisesti huomattavasti halvempaa kuin virheen havaitseminen, tunnistaminen ja korjaaminen myöhemmin. Jos ohjelma julkaistaan virheellisenä, sen koodissa esiintyvät virheet aiheuttavat helposti kalliita ongelmia ohjelmiston loppukäyttäjille. Huonosti kirjoitettua koodia voi olla mahdotonta tai vaikeaa yksikkötestata, joten yksikkötestaus usein pakottaa kehittäjät kirjoittamaan parempaa koodia. Yksikkötestauksen etuja ovatkin juuri automaatio ja hyvän yksikkötestauksen tuoma varmuus testattujen luokkien toiminnasta[8].[9]
Testivetoisessa kehityksessä (TDD), jota käytetään usein ohjelmistokehityksessä ja scrumissa, luodaan yksikkötestit jo ennen itse koodin kirjoittamista. Kun testit suoritetaan hyväksytysti, kyseinen koodi katsotaan valmiiksi. Samaa yksikkötestiä ajetaan kyseistä usein, aina kun suurempaa koodikantaa kehitetään, joko koodin muuttuessa tai automatisoidun prosessin avulla rakennuksen yhteydessä. Jos yksikkötestit eivät läpäise testiä, se katsotaan joko virheeksi muuttuneessa koodissa tai testeissä itsessään. Yksikkötestit mahdollistavat vian tai virheen jäljittämisen helposti. Koska yksikkötestit ilmoittavat kehittäjille ongelmasta ennen kuin koodi siirretään testaajille tai asiakkaille, mahdolliset ongelmat havaitaan varhaisessa vaiheessa kehitysprosessia.[10]
Yksikkötestaus mahdollistaa koodin myöhemmän refaktoroinnin tai järjestelmäkirjastojen päivittämisen, jolloin varmistetaan, että moduuli toimii edelleen. Menettelyssä kirjoitetaan kaikille funktioille ja metodeille testitapauksia, jotta aina kun muutos aiheuttaa virheen, se myös tunnistetaan mahdollisimman nopeasti. Yksikkötestit havaitsevat sellaiset muutokset, jotka saattavat rikkoa ohjelmistolle asetetut vaatimukset.[11]
Järjestelmän toiminnan dokumentointi muokkaa
Yksikkötestaamisen dokumentointi ja raportointi on keskeinen osa ohjelmistoprojekteissa, jotka noudattavat ketteriä menetelmiä, laatuvaatimuksia tai sääntelyvaatimuksia. Dokumentoinnin laatiminen auttaa osoittamaan toteutettujen yksikkötestiesi kattavuuden ja täydellisyyden sekä tunnistamaan ja priorisoimaan virheitä. Niin ikään dokumentointi auttaa jakamaan palautetta ja kehitysehdotuksia projektin tiimin ja sen sidosryhmiesi välillä. Lisäksi kattavasti laadittu dokumentointi auttaa tarkastelemaan ja hienosäätämään projektin testausstrategiaa ja näin parantaa koodin laatua.[12]
Yksikkötestaus tarjoaa elävän dokumentaation kehitettävästä järjestelmästä. Kehittäjät, jotka haluavat oppia, millaisia toimintoja tarkasteltava yksikkö tarjoaa ja miten sitä käytetään, käyttävät yksikkötestejä saadakseen lähtökohtaisen käsityksen yksikön rajapinnasta (API). Yksikkötestitapaukset ilmentävät ominaisuuksia, jotka ovat kriittisen tärkeitä yksikön toiminnallisuuden toteutumisen kannalta. Nämä ominaisuudet saattavat osoittaa joko sopivan tai sopimattoman tavan käyttää yksikköä sekä myös niin sanotut negatiiviset käyttäytymismallit, joita yksiköllä ehkä on. Yksikkötestitapaus itsessään dokumentoi näitä kriittisiä ominaisuuksia, vaikkakin monet ohjelmistokehitysympäristöt eivät perustu pelkästään siihen, että koodi dokumentoi kehitteillä olevaa tuotetta. Toisaalta jotkut kehitysympäristöt tarjoavat mahdollisuuden automaattisesti generoida dokumentaatiota testitapauksista: tämä dokumentaatio on esimerkiksi HTML-raportti, joka tarjoaa yksityiskohtaisen yhteenvedon yksikkötesteistä ja niiden tuloksista.
Kun ohjelmistoa kehitetään testivetoisella lähestymistavalla, yksikkötestin kirjoittaminen rajapinnan määrittämiseksi yhdessä testiläpäisyn jälkeen kirjoitettavien refaktorointitoimenpiteiden kanssa, saattaa joissakin tapauksissa korvata muodollisen suunnittelun. Jokainen yksikkötesti itsessään on tavallaan luokkia, metodeja ja käyttäytymishavainnointia määrittelevä suunnitteluelementti.
Dokumentaation ylläpitäminen kehittyvän koodipohjan kanssa on haasteellista, sillä dokumentaatio vanhentuu helposti uusien ominaisuuksien lisääntyessä. Tämän välttämiseksi on suositeltavaa pitää projektin dokumentaatio samassa arkistossa kehitettävän koodin kanssa ja näin mahdollistetaan laadukkaan "commitin" luominen, joka sisältää koodimuutoksen, päivitetyt yksikkötestit ja niihin liittyvän dokumentaation samassa kokonaisuudessa.[13]
Haittapuolet ja rajoitteet muokkaa
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.[14] 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. [15][16]
Yksikkötestauksessakaan ei havaita jokaista ohjelman virhettä, koska se ei pysty arvioimaan jokaista suorituspolkua muissa kuin triviaalisimmissa ohjelmissa. Tämä ongelma on ratkaisematon. 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.[17][18]
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.[19]
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 paljastuu, 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.[20]
Sulautetun järjestelmäohjelmiston yksikkötestaus on ainutlaatuinen haaste yksikkötestauksessa. Koska tämä ohjelmisto kehitetään eri alustalle kuin millä se lopulta ajetaan, testiohjelma ei kovinkaan helposti toimi ohjelman käyttöympäristössä kuten vaikka työpöytäohjelmien kanssa.[21]
Ketterä ohjemistokehitys yksikkötestauksessa muokkaa
Ketterässä ohjelmistokehityksessä kehitysprosessi koostuu iteratiivisista vaiheista, joita kutsutaan sprinteiksi ja joista jokainen sisältää suunnittelu-, koodaus- ja testausvaiheet. Yhden sprintin aikana, kun ohjelmistoprojektin vaatimukset on kerätty ja kehitysprosessi on jo suoritettu, suoritetaan yksikkötestaus. Ketterän ohjelmistokehitysparadigman perusteella yksikkötestausta ei välttämättä tarvitse tehdä tiukasti yksittäisen sprintin loppuvaiheessa, mutta yleensä se tapahtuu tässä vaiheessa[22][23].
Yleensä yksikkötestaus käsittää yhden käyttäjätarinan. Pohjimmiltaan jotkut tiimin jäsenet kirjoittavat testiskriptit, jotka ohjelmistokehittäjät sitten suorittavat. Näiden skriptien tarkoituksena on testata joitakin erittäin spesifisiä ohjelmiston osia arvioidakseen uusien osien oikean toiminnan ja tehokkuuden, mikä on varsin tehokasta juuri ketterässä ohjelmistokehityksessä, koska sprinttien avulla kehittäjät voivat sopeutua uusiin vaatimuksiin ja ohjeisiin varsin nopeasti. Tämä vähentää riskiä joutua noudattamaan tiukkaa, ennalta määritettyjä vaatimusten sarjaa kehitysprosessin alusta loppuun asti.
Jos yksikkötesti epäonnistuu, kaikki tiedot dokumentoidaan, mukaan lukien yksikkötestin syötteet, odotetut tulokset, todelliset tulokset ja vaiheittaiset ohjeet siitä, kuinka samat tulokset voidaan toistaa. Lisäksi, jos virheitä ilmenee, kehitys palaa sprintin suunnittelu- ja koodausvaiheisiin.
Toisaalta, jos testiskripti palauttaa odotetut tulokset, yksikkötesti voidaan luokitella ”läpäistyksi”. Tällöin kehitys siirtyy sprintin viimeisiin vaiheisiin. Näiden vaiheiden aikana suoritetaan joitakin tärkeitä testausvaiheita, kuten koodin tarkistusta. Tämän jälkeen edistymisestä raportoidaan sidosryhmille, jotka lopulta päättävät, ovatko tulokset tyydyttäviä vai eivät[23].
Testaamisen työkalut muokkaa
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
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
- ↑ 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.
- ↑ Boehm, Barry W. Papaccio, Philip N.: Understanding and Controlling Software Costs, s. 1462-1477. IEEE, Transactions on Software Engineering., 1988. doi:10.1109/32.6191.
- ↑ Yksikkötestaus Tampereen yliopisto. Viitattu 04/07/2023.
- ↑ Unadkat, Jash.: What is Test Driven Development (TDD)? browserstack.com. 14. kesäkuuta, 2023. Viitattu 04/07/2023.
- ↑ Savoila, Petja.: Kuntoon laitettu koodi on merkittävä kilpailuetu meom.fi. 20/12/2019. Viitattu 04/07/2023.
- ↑ How do you document and report the results and issues of unit testing? www.linkedin.com. Viitattu 23.7.2023. (englanniksi)
- ↑ Simon Willison: Documentation unit tests Medium. 28.7.2018. Viitattu 23.7.2023. (englanniksi)
- ↑ 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.
- ↑ Agile software development. Wikipedia, 4.10.2023. Artikkelin verkkoversio. en
- ↑ a b Unit testing. Wikipedia, 18.10.2023. Artikkelin verkkoversio. en