Ohjelmistotestaus voidaan jakaa eri tasoihin. Yksikkötestaus on “matalimman” tason testausta, jossa testataan yksittäisiä metodeja ja algoritmeja ilman riippuvuuksia muihin komponentteihin. Yksikkötestaus ei ole vain laadunvarmistusta. Yksikkötestaus luo pohjan laajemmille käyttötapaustesteille ja integraatiotesteille. Yksikkötestausta voidaan myös hyödyntää koodin rakenteen muokkaajana, sekä idean jalostamisessa.
Testaus mielletään helposti ohjelmiston laadunvarmistus keinoksi, joka on erillään muusta kehityksestä. Syöte sisään ja tarkistetaan tulos. Jos tulos on oikein, ohjelmisto tai sen osa toimii oikein. Tämä on kuitenkin vain pieni osa kokonaisuuttaa. Yksikkötestauksella on muitankin funktioita ohjelmistokehityksessä. Yksikkötestaus toteutettuna testausensin metodilla (Test Driven Development, TDD) voi parhaimmillaan säästää rahaa tulevaisuudessa. Alla on muutamia esimerkkejä yksikkötestien hyödyistä.
- TDD muokkaa koodista testattavampaa
- Kattavasti testattu koodi on helpommin ylläpidettävä
- Testit pakottavat miettimään, mikä on tärkeää
- Testit dokumentoivat ohjelmistoa
- Testit perehdyttävät uuden tiimiläisen ohjelmiston toimintaan
- Testin kirjoittaminen pysäyttää kehittäjän ajattelemaan ratkaistavaa ongelmaa
Yksikkötestaus sekä muut testit osana ohjelmiston rakenteen ja idean muokkaajana
Parhaimmillaan ohjelmakoodi on aina saman näköistä, riippumatta koodin kirjoittajasta. Ohjelmistokoodi ei ole kirjallisuutta, joten sen ei tarvitse muistuttaa kirjoittajan tyyliä eikä koodin lukemisen tarvitse aiheuttaa suuria tunteita. Koodissa juonen käänteiden olisi hyvä noudattaa aina samaa kaavaa. Hyvä koodi on tylsää ja persoonatonta. Koska koodi on tylsää ja tarinatonta, pitää myös kappaleiden olla lyhyitä, jotta lukija voi helposti keskeyttää lukemisen muutaman rivin jälkeen.
Testaus ensin menetelmällä yhden mukaistetaan ja pilkotaan koodia. Testaus ensin menetelmässä ohjelmoija joutuu kirjoittamaan ominaisuudelle testin ennen itse ohjelmakoodin kirjoittamista. On helpompaa kirjoittaa paljon yksinkertaisia testejä ja niille ratkaisu, kuin iso kaiken kattava testi ja sille ratkaisut. Tästä seuraa väistämättä pienempiä ja yksinkertaisempia ominaisuuksia. Testien vaatiminen myös pilkkoo turhia riippuvuuksia muista komponenteista, koska testejä on mahdoton kirjoittaa komponenteille, jotka vaativat kaiken muun koodin ympärilleen.
Testien kirjoittaminen on työlästä ja hidastaa uusien ominaisuuksien toteutusta, mikä on loistava asia. Ohjelmistokehityksessä luodaan helposti ominaisuuksia, joita ei koskaan käytetä. Nämä lisämausteet voivat vähentää ohjelmiston käytettävyyttä sekä lisäävät monimutkaisuutta. Mitä vähemmän ominaisuuksia, sitä helpompi ohjelmaa on käyttää ja ymmärtää.
Koska jokaiselle ominaisuudelle on testi, on koodin muokkaaminen ja laajentaminen helpompaa ja riskittömämpää. Koodimuutoksesta koodaaja saa heti palautteen särkyikö jotain. Valitettavasti edes yksikkötesti ei aina poista uusien ominaisuuksien lisäämisestä koituvia käytettävyys haasteita, mutta on kuitenkin aina mukavampi olla varma siitä, että vanhat ominaisuudet voisivat toimia.
Yksikkötestaus ja muut testit osana dokumentointia
Agile manifest sanoo “Parempi toimiva ohjelmisto kuin kattava dokumentointi”. Dokumentoinnilla on kuitenkin tärkeä funktio ohjelmistokehityksessä. Dokumentointi kertoo ihmisille, miten ohjelmisto toimii ja miten sitä käytetään. Käytännössä ohjelmisto toimii aina niin kuin se on koodattu. Koodi on ainoa ajantasalla oleva dokumentti. Hyvät dokumentoijat voivat saada perinteiset dokumentit hetkellisesti ajantasalle, käytännössä kuitenkin jossain kohtaa dokumentointi ja koodin kehitys eivät enää mene käsikädessä.
Kun dokumentit sanoo yhtä ja koodi toista, mitä uskoa? Ohjelmisto kuitenkin toimii kuten koodi sitä ohjaa, jolloin dokumenttien arvo murenee. Toisaalta koodia ymmärtämätön voi vain lukea dokumenttia tai kokeilla ohjelmaa. Myös koodia ymmärtävälle, pelkän koodin lukeminen ilman kontekstia on hidasta.
Testit avaavat ohjelmiston toimintaa. Otsikkotasolla testit kertovat mitä eri komponentit on ajateltu tekevän. Testien toteutuksesta taas näkee, mitä ohjelmoija on ajatellut komponentin tekevän. Kattavuus luvusta taas voi arvioida erilaisten yllätysten määrää. Testit eivät takaa ohjelmiston laatua, mutta ne auttavat ymmärtämään koodia paremmin, mikä voi parantaa laatua.
Uusi tiiminjäsen oppii ymmärtämään eri komponenttien toimintaa lukemalla testejä. Kontektstin hän saa käyttötapaustesteistä ja toteutus detailit yksikkötesteistä.
Yksikkötestit Devolutionin käytössä
Devolutionin kehitysprosessi hyödyntää eri tasoisien kehittäjien verkostoa. Annamme kehittäjillemme vapauden vaihtaa projektia, sekä valita itse tehtävät. Jotta tämä toimii, tarvitsemme kattavat yksikkötestit varmistamaan koodin rakenteen yhteneväisyyttä, varmistamaan jatkokehityksen sekä helpottamaan komponenttien toiminnan ymmärrystä. Käytännössä jokainen koodi inkrementtimme sisältää yksikkötestin ja ohjelmistokoodin. Meillä on periaate: “Jos ei ole testiä, ominaisuutta ei ole”.