Testikattavuuden ja suorituskyvyn parantaminen Test Pyramidin avulla

Automaattisten testien kirjoittaminen voi olla haastavaa tämän tyyppisen koodauksen erityispiirteiden vuoksi. Jos aiot käyttää niitä DevOps-ohjelmistokehitysprosessissa, jossa automaatiota hyödynnetään laajasti sekä testauksessa että infrastruktuurissa koodina, testien on tärkeää toimia nopeasti ja luotettavasti. Epäluotettaville testeille on oma määritelmänsä, kuten Google Testing Blog kuvaa: ”Flaky tests are tests that exhibit both a passing and a failing result with the same code”. Tällaiset testit voivat pilata putken, aiheuttaa vääriä positiivisia tuloksia ja johtaa QA-tiimin vääriin päätelmiin testikokonaisuuden läpäisyasteesta.

UI-testit noudattavat käyttäjän toimintaa, joten voit varmistaa koko ohjelmiston toiminnallisuuden käyttäjän näkökulmasta. Ne tuottavat konkreettista liiketoiminta-arvoa, toisin kuin esimerkiksi sen testaaminen, onko JSONin luova funktio oikeassa muodossa. Tämä on Google Testing Blog -artikkelin ”Just Say No to More End-to-End Tests” keskeinen viesti. Artikkelissa käsitellään UI-testauksen käytännön puolia ja kuvataan testejä epäluotettaviksi, juurisyyn jäljittämisen kannalta hankaliksi sekä pienet virheet suurempien virheiden sisään piilottaviksi, sillä useimmat poikkeukset ohitetaan ja käyttöliittymässä näytetään vain mukautettuja varoituksia.

Tämän ajattelutavan muuttamisen tueksi Martin Fowler esittelee testipyramidin, havainnollisen vertauskuvan, joka auttaa pohtimaan testauksen eri tasoja ja sitä, kuinka paljon testejä tulisi suhteellisesti sijoittaa kullekin tasolle. Pyramidista mainittiin ensimmäisen kerran Mike Cohnin kirjassa ”Succeeding with Agile”, mutta Martinin mukaan se on liian yksinkertaistettu ja voi siksi johtaa harhaan.

Tarkastellaan Martinin päivittämää testipyramidin modernia käsitettä:

Pyramidin muoto havainnollistaa tämän lähestymistavan kahta asiaa. Ensinnäkin se osoittaa, kuinka paljon testejä kullakin tasolla tulisi toteuttaa: pyramidin alaosassa testejä on enemmän kuin ylimmällä tasolla. Toiseksi se havainnollistaa kunkin tason suorittamiseen tarvittavia resursseja. Alhaalla olevat yksikkötestit suoritetaan nopeasti ilman kolmannen osapuolen sovelluksia, kun taas ylimpänä olevat UI-testit käyttävät esimerkiksi selainta ja Selenium Serveriä. Testiluokkien jakautuminen on täysin linjassa näiden kahden mittarin kanssa. Katsotaan tätä tarkemmin:

1. Yksikkötestit: Keskittyvät koodin pienimmän funktion testaamiseen. Tavoitteena on varmistaa, että funktio osaa vastaanottaa syötteen ja käsitellä sen suunnitellulla tavalla. Voit mockata tai stubata syötteen, jotta testi ei riipu muista komponenteista.

2. Komponenttitestit: Testaavat ohjelmiston kokonaisen komponentin ilman käyttöliittymää. Komponentti on sovelluksen moduuli. Tällä tasolla testissä aletaan varmistaa liiketoimintasääntöjä, sillä pienemmät funktiot on jo testattu yksikkötestien tasolla.

3. Integraatiotestit: Testaavat arkkitehtuurin kahden komponentin välistä viestintää. Tavoitteena on varmistaa, että komponentit voivat kommunikoida keskenään. Jos nämä komponentit käyttävät tietoa järjestelmän muista osista, kuten API-rajapinnoista tai muista moduuleista, ne voidaan mockata tai stubata. Tälle tasolle voidaan sisällyttää myös muita testejä: sopimustesti, joka varmistaa, että API noudattaa määriteltyä malliaan, sekä kuluttajatesti, joka varmistaa, että toisista API-rajapinnoista tietoa vastaanottava koodin osa pystyy hyödyntämään sitä. Myös syöte voidaan mockata.

4. End-to-End: Testaa koko ohjelmiston käyttöliittymän kautta.

5. Tutkiva/manuaalinen testaus: Osa UI-testeistä on niin monimutkaisia, että niiden automatisointi voi olla vaikeaa. Ne voidaan siksi suorittaa manuaalisesti. Jotkin monimutkaiset työnkulut voidaan myös tunnistaa sovelluslokeja analysoivalla työkalulla, kuten Splunkilla, jolloin QA-tiimi voi kartoittaa ne ja ryhtyä toimiin testin automatisoimiseksi.

6. Sopimustesti, joka varmistaa, että API noudattaa määriteltyä malliaan.

7. Kuluttajatesti, joka varmistaa, että toisista API-rajapinnoista tietoa vastaanottava koodin osa pystyy hyödyntämään sitä. Myös syöte voidaan mockata.

Yksikkötestit ovat helppoja kirjoittaa ja niiden suorittaminen on hyvin edullista. Niitä kirjoitettaessa kannattaa käyttää aikaa toiminnallisuuden varmistamiseen ja selvittää tarkasti, toimiiko funktio ennakoidulla tai odotetulla syötteellä ja miten se käsittelee odottamattomia tai virheellisiä syötteitä. Komponenttitestien tasolla on aika unohtaa yksikkötestien kattamat pienet toiminnallisuudet ja varmistaa ohjelmiston liiketoimintasäännöt.

Integraatiotestien on katettava muutakin kuin komponenttien välisen viestinnän odotetut tapaukset. Niiden on kyettävä tulkitsemaan komponentin virheilmoituksia ja tunnistamaan, milloin palautetaan poikkeuksia, joita sovellus voi käsitellä. Muista stubata tai mockata kaikki, mitä ei tässä laajuudessa testata. Jos testaat esimerkiksi tietokantayhteyttä, sinun ei tarvitse muodostaa yhteyttä todellisiin kolmannen osapuolen API-rajapintoihin.

End-to-End-testien on testattava sovelluksen tärkeimmät käyttäjäpolut. Näitä testejä tulee olla vähemmän kuin aiempien tasojen testejä, sillä ne kattavat jo suuren osan sovelluksesta. Testejä ei tarvitse kahdentaa.

Lopuksi:

Pelkästään UI-testeihin perustuva sovellusten testaus aiheuttaa pitkällä aikavälillä suuria kustannuksia ja epävarmuutta testien epäluotettavuuden vuoksi. Testipyramidi on hyvä käytäntö DevOps-ohjelmistokehitysprosessissasi, sillä se on edullisempi, nopeampi ja luotettavampi.