Muutakin ohjelmointia tavalliselle koodaajalle, osa 1: Kaikki koodaajat testaavat

Harva kiistää testauksen keskeistä roolia ohjelmistokehityksessä, mutta arvostus ei aina näy käytännön teoissa. Päätin ottaa itseäni niskasta kiinni ja ryhtyä tutkimaan, mitä kaikkea ohjelmistotestauksen parissa voi nykyteknologioilla tehdä. Tämä blogiteksti on ensimmäinen merkintä aiheen tiimoilta.

Monen muun koodaajan tapaan ensimmäinen oma koodausprojektini oli tekstiseikkailupeli. Nimensä mukaisesti peli rakentuu ruudulle ilmestyvästä tekstistä. Pelaaja liikuttaa hahmoja kirjoittamalla käskyjä kuten mene pohjoiseen, avaa ovi, sano terve, ota miekka. Käskyn seurauksena tarina jatkuu johonkin suuntaan. Yksinkertaista, ajattelin, ja ryhdyin hommiin. Ensinnäkin halusin, että sovellus kysyy pelaajan nimen, joka sitten ilmestyisi ruudun yläpalkkiin. Kun olin kirjoittanut funktion, joka ottaa vastaan pelaajan syöttämän merkkijonon ja tallentaa sen muuttujaan, käynnistin sovelluksen ja kirjoitin nimeni ruudulle. Testasin, että kaikki toimii niin kuin pitää.

Siihen asti kaikki oli helppoa ja nopeaa, mutta jo ensimmäisen pelattavan huoneen kohdalla tuli haasteita. Mitä enemmän käskyjä, sitä enemmän vaihtoehtoja ja mahdollisuuksia virheille. Entä jos pelaaja painaa vahingossa enteriä ja syötteeksi tulee tyhjä merkkijono? Entä jos olen unohtanut kirjoittaa jollekin käskylle vastauksen? Ohjelma hyväksyy pelaajan syötteen mutta ei osaa käsitellä sitä. Huoneet olivat myös erilaisia keskenään. Jos halusin testata toisessa tai kolmannessa huoneessa olevaa toiminnallisuutta, minun oli pelattava peli sinne asti ennen kuin pääsin edes aloittamaan. Jos koodaamisessa oli viikonkin tauko, tilanne paheni entisestään, sillä olin ehtinyt unohtaa suurimman osan siitä, mitä olin tehnyt. Kunpa voisi vain painaa nappia ja joku ohjelma kävisi kaikki mahdolliset syötteet ja virhetilanteet silmänräpäyksessä läpi…

Ongelmasta ratkaisuihin

En ole ensimmäinen koodaaja, jolle ajatus on tullut mieleen. Itse asiassa ongelman ympärille on kasvanut kokonainen ohjelmistokehityksen haara. On yksikkötestausta, integraatiotestausta, regressiotestausta, end-to-end-testausta, UI-testausta ja tietenkin erilaisia työkaluja niiden suorittamiseen, automatisointiin ja analysointiin. Kaikki koodaajat testaavat, mutta miten he sen tekevät, on toinen juttu, eikä vähiten kyse ole tyylistä. Sanomattakin selvää, että tekstiseikkailupelini manuaalinen testaus ei minulle tyylipisteitä tuonut.

Ylläpito- ja pienkehityshommissa Orangitilla automaattitestien merkitys ja hyöty tulevat vastaan jokapäiväisessä työssä. Rutiinitehtäviin kuuluvat esimerkiksi riippuvuuksien päivitykset. Ei ole järkevää koodata kaikkea alusta alkaen itse vaan tavallista on hyödyntää olemassa olevaa koodia eli niin sanottuja paketteja tai koodikirjastoja. Niin kuin mitä tahansa koodia paketteja pitää päivittää, jotta ne pysyvät elinvoimaisina ja tietoturvallisina. Pieniä ja isoja muutoksia julkaistaan jatkuvasti, ja meidän tehtävämme sovelluksen ylläpitäjinä on huolehtia, että hallussamme olevan koodin riippuvuudet ovat ajan tasalla. Itse paketin päivitys hoituu nykyisillä työkaluilla yhdellä klikkauksella, mutta jonkun tai jonkin pitää varmistaa, toimiiko koodi päivityksen jälkeen. Ideaalitapauksessa päivitys triggeröi automaattitestit, ja jos kaikki testit menevät läpi, kehittäjän osuus prosessissa oli siinä. Jos päivitys vaatii muutoksia koodiin, testit kertovat senkin, prosessi pysähtyy eikä jatku ennen kuin koodi on korjattu.

Orangitilla on myös tavallista, että yhden työpäivän aikana joutuu koskemaan useampaan ohjelmaan. Lisäykset ja korjaukset ovat suhteellisen pieniä, etenkin jos vertaa kehitysvaiheessa olevaan sovellukseen, ja usein on oltava nopea. Ketterä siirtyminen sovelluksesta toiseen ei olisi mahdollista, jos pienikin muutos koodiin aiheuttaisi kohtuutonta pelkoa siitä, että jotain on saattanut mennä rikki. Kattava manuaalinen testaus on vaivalloista ja inhimillisten virheiden vääjäämättömyys ajaa vähänkään neuroottisen ohjelmistokehittäjän ennen pitkää hermoromahduksen partaalle. Testit ovat pelastusrengas, joka pitää aikapaineiden ja vaatimusten aallokossa luovivat koodaajat selväjärkisinä.

Miksi testejä ei sitten kirjoiteta?

Jos automaattitestien hyöty on kiistaton ja puitteet niiden luomiselle ovat erinomaiset, miksi niiden potentiaali jää monesti pitkälti hyödyntämättä? Tehdään pakolliset testit mutta ennemmin velvollisuudesta kuin suunnitelmallisesti niin, että niihin voidaan sitten aidosti tukeutua. Omissa koodausprojekteissa täytyy lähinnä vastustaa vauhdin hurmaa. Tekisi mieli paahtaa eteenpäin, siirtyä uuteen toiminnallisuuteen vaikka edellinen on vielä työn alla. Testien kirjoittaminen ei ainoastaan hidasta uuden luomista vaan tuntuu lyövän jarrut pohjaan. Kuin joku vaatisi joka ikisen lauseen kohdalla pysähtymään ja pohtimaan sanojen merkityksiä ja yhteyksiä, kun itse haluaisi vain kertoa tarinan loppuun. Ongelma kuitenkin ratkeaa parin minuutin itsetutkistelulla. Mikä minua koodaamisessa itse asiassa kiehtoo? Vastaus on yksinkertaisesti koodin kirjoittaminen, ja kun olen palauttanut mieleeni, että testien laatiminen tarkoittaa käytännössä usein koodaamista, olen taas onnellinen.

Työelämän projekteissa syyt ovat ne tavalliset: aika ja raha. Testien ajaminen on vaivatonta, mutta vaivattomuutta edeltää aina suuri vaiva ja vaivannäkö maksaa aikaa ja rahaa. Kysymys kuuluukin, maksaako vaiva itsensä takaisin. Säästävätkö testit lopulta aikaa? Voiko tai uskaltaako niiden ansiosta tiputtaa kehitysprosessista manuaalisia vaiheita pois? Saako niistä hyödyllistä tietoa? Nämä ovat tärkeitä kysymyksiä, eivätkä testit sinänsä takaa myönteistä vastausta. Monessa aiheesta kuuntelemassani podcastissa toistuvat käsitteet suunnittelu ja luottamus.¹ Testit ovat hyödyllisiä vain jos niihin voi luottaa ja sellaisten testien laatiminen vaatii suunnitelmallisuutta. Pahin tilanne on, jos testejä kirjoitetaan ja ylläpidetään, koska niin kuuluu tehdä, mutta niiden varaan ei uskalleta heittäytyä prosessin missään vaiheessa.

Väittäisin kuitenkin, että valtaosassa projekteista automaattitesteihin panostaminen on lopulta kannattavaa. Panostus näkyy kieltämättä laskussa, mutta kustannukset ovat vain hetkelliset — ja ne ylipäätään näkyvät. Manuaalitestaukseen kuluva aika jää helposti piiloon ja niin myös sen todellinen hinta. Lisäksi inhimillisten virheiden kasvava riski paitsi kalvaa kehittäjää myös heikentää sovelluksen ylläpidettävyyttä kasvattaen kuluja pitkässä juoksussa.

Orangitilla meitä työntekijöitä rohkaistaan omien kiinnostuksen kohteiden pariin ja niissä kehittymistä pyritään tukemaan. Minua henkilökohtaisesti kiinnostaa testaus, ja verkkokurssien ja käytännön harjoitusten lisäksi tämä blogi on tapa kerryttää tietämystä ja jakaa sitä. Lisää tekstejä testauksesta on siis luvassa.

Haluaisitko liittyä joukkoomme? Etsimme uusia koodaajia tekemään ylläpidosta — ja testauksesta! — siistiä.

[1] Esim. Webbidevaus, Software Engineerin Radio jaThe Cynical Developer.