Yksikkötestien hyödyllisyys web-ohjelmistokehityksessä

Tämä kirjoitus on tieteellisillä vivahteilla maustettu jatko-osa Joonas Pajusen automatisoitua testausta käsittelevään blogautukseen. Kirjoituksessa käsitellään yksikkötestaamista, eikä niinkään testiautomaatiota.

Yksikkötestien kustannustehokkuus ja hyödyllisyys web-ohjelmistokehityksessä eivät kulje aina käsi kädessä. Pro gradu -tutkielmani puitteissa tehdyn kyselytutkimuksen tuloksista onneksi näkee, että useat ohjelmistoyritykset pitävät yksikkötestien laatua määrää tärkeämpänä.

Kyselyyn vastanneiden yritysten mukaan yksikkötasolla testaaminen ei ole kaikkiin ongelmiin soveltuva testausmenetelmä. Vastaajien mukaan yksikkötestit soveltuvat parhaiten ohjelmiston osiin, joiden täsmällinen toiminta on liiketoiminnan kannalta kriittistä.

Tutkimuksen tulokset olivat linjassa James O. Coplienin artikkeleiden [1] ja Is TDD Dead -debatissa [2] esiintyneiden mielipiteiden kanssa. Molemmissa lähteissä tuotiin esille yksikkötestaamisen tukemiseen liittyviä ongelmia, joita esimerkiksi ohjelmiston arkkitehtuuriin syntyvät ylimääräiset kerrokset edustavat. Tulokset ja molemmat edellämainitut lähteet olivat samaa mieltä yksikkötestien soveltuvuudesta monimutkaisten algoritmien testausmenetelmäksi.

Muitakin Is TDD Dead -debatissa ilmenneitä ongelmia [2] tuli esiin kyselyn vastauksista. Varsinkin testitynkien (engl. mock) liiallinen käyttö ja monimutkaisten testitynkäviritelmien varaan rakennetut testit koettiin testien laatua heikentäväksi tekijäksi. Tieteellisissä tutkimuksissa ja testauskirjallisuudessa tätä ongelmaa ei kuitenkaan juuri olla käsitelty aikaisemmin.

Tutkimuksesta

Tutkimus suoritettiin keväällä 2015 lähettämällä kyselylomake 27 web-ohjelmistokehitystä konsulttityönä tekevään yritykseen. Yrityksistä 9 vastasi kyselyyn. Kyselyyn osallistuneiden yritysten projektien luonteet on esitetty taulukossa 1.

Fraktio yksikkötestien hyödyllisyys Kai Kulju Taulukko 1. Kyselyyn vastanneiden yritysten projektien luonteet

On huomioitava, että tutkimuksen lähestymistapa oli luonteeltaan kvalitatiivinen ja sen vuoksi tuloksista ei voi johtaa yleistyksiä. Uusia internetin blogeissa ja muilla foorumeilla esiin tulleita ilmiöitä ja ongelmia tutkimuksen perusteella kuitenkin vahvistettiin.

Tulokset

Vastaajien keskuudessa yksikkötestaamista ei pidetty laadunvarmistuksen hopealuotina ja yleisesti tunnustettiin, että muita laadunvarmistusmenetelmiä tarvitaan ohjelmistokehityksen tueksi. Yksikkötestejä pidettiin kuitenkin hyödyllisinä.

Kaikki kyselyyn vastanneet yritykset ilmoittivat noudattavansa yksikkötestin yleistä määritelmää tai hieman laveampaa – enemmän integraatiotestiä muistuttavaa – määritelmää, jossa on vähemmän tarvetta testityngille.

Tuloksista kävi ilmi, että yksikkötestaaminen ei ole täysin ongelmatonta. Vahvasti testitynkiin nojaavat testit koettiin haitallisiksi ja vaikeasti ylläpidettäviksi. Samoja asioita useaan kertaan testaavat testit olivat monen vastaajan mielestä turhia, testien suorittamista hidastavia ja kehitysnopeuteen negatiivisesti vaikuttavia. Lisäksi turhien testien lisäämä suoritusaika johti yleisesti siihen, että testejä ei suoriteta niin usein kuin olisi tarpeen.

Taulukossa 2. on havainnollistettu vastaajien kokemat yksikkötestaamiseen liittyvät ongelmat.

Fraktio yksikkötestien hyödyllisyys Kai Kulju Taulukko 2. Yksikkötestaamisen ongelmat yksikkötestaamista aktiivisesti harjoittavien yritysten keskuudessa

Kyselyn yhdeksästä vastaajasta kuusi ilmoitti tekevänsä aktiivisesti yksikkötestausta. Taulukosta näkee, että yksikkötestaamisen ongelmat liittyivät turhiin testeihin, liialliseen testaukseen tai tynkien monimutkaisuuteen.

Kolme kyselyyn vastannutta yritystä piti yksikkötestejä ylivertaisena työkaluna algoritmien ja liiketoimintalogiikan testaamisessa. Kaksi vastaajista suhtautui yksikkötesteihin kuitenkin enemmän arkisena kehitystyökaluna kuin varsinaisena laadunvarmistusmenetelmänä.

Kyselyyn vastanneet yritykset voitiin jakaa karkeasti kahteen ryhmään. Ensimmäinen ryhmä piti yksikkötestaamista aina hyödyllisenä asiana, joka nopeuttaa kehitystä. Toinen ryhmä taas suhtautui yksikkötestaamiseen enemmän liiketoimintakriittisestä näkökulmasta, jossa yksikkötestien olemassaolo täytyy voida perustella tapauskohtaisesti.

Yksikään vastaajista ei ilmoittanut mittaavansa yksikkötestien tehokkuutta ja osa piti ajatusta suorastaan naurettavana. Vastaajista useat kuitenkin sanoivat seuraavansa testien läpimenoa tai epäonnistumista jatkuvan integraation palvelimilta (engl. continuous integration).

Vastaajien keskuudessa suosituimpia laadunvarmistusmenetelmiä yksikkötestaamisen ohella olivat integraatiotestit, selaimessa suoritettavat toiminnalliset testit, jatkuva integraatio, tutkiva testaus, pariohjelmointi, käytettävyystestaus, koodausstandardit ja koodikatselmoinnit.

Suosituksia testaamiseen

Seuraavat suositukset on jalostettu kyselytutkimukseen vastanneiden yritysten vastauksista ja kirjallisuudessa esiintyneistä mielipiteistä. Nämä ovat myös kirjoittajan mielestä olennaisia.

Keskittykää rajapintojen testaamisen sijaan käyttötapauksiin pohjautuviin testeihin[1].

You can usually reduce your test mass with no loss of quality by testing the system at the use case level instead of testing the unit at the programming interface level.
Käyttäkää laajaa valikoimaa toisiaan tukevia eri testaus- ja laadunvarmistusmenetelmiä [1].

Testing — whether at the unit, system or integration level — at its very best can catch only a fraction of the faults that arise in software. Teams should use a broad repertoire of quality assurance techniques to remove defects.
Tehkää tutkivaa testausta (engl. exploratory testing), sillä löytää virheitä tehokkaasti[3, s. 503].
Painottakaa yksikkötestausta enemmän algoritmiseen ohjelmakoodiin ja keskittykää muihin osa-alueiseen käyttöliittymään painottuvassa ohjelmakoodissa [4, s. 48].
Älkää tehkö huonoja yksikkötestejä 😉 [5].
Välttäkää liian monimutkaisia tynkäviritelmiä [2].
Prototyyppivaiheessa laatuun tai testiautomaatioon panostaminen ei kannata [4, s. 23].
Testien määrä ei korvaa laatua [1].

If you want to reduce your test mass, the number one thing you should do is look at the tests that have never failed in a year and consider throwing them away. They are producing no information for you — or at least very little information. The value of the information they produce may not be worth the expense of maintaining and running the tests. This is the first set of tests to throw away — whether they are unit tests, integration tests, or system tests.
Testiautomaatiolla ei välttämättä saada kustannussäästöjä [1].

Remember, though, that automated crap is still crap.