Hacker Newsissä nousi hiljattain pinnalle Kostis Kapelonis’n erinomainen artikkeli Software Testing Anti-patterns. Artikkeli keräsi huimat 465 ääntä ja 166 kommenttia – eikä syyttä. Se kokoaa yhteen 13 yleistä testauksen antipatternia, jotka ovat tuttuja jokaiselle testausammattilaiselle.
Tässä kirjoituksessa käyn läpi Kapelonis’n listaamat antipatternit ja pohdin niiden merkitystä suomalaisen testauskentän näkökulmasta.
Testipyramidi – perusta, joka usein unohdetaan
Kapelonis aloittaa testipyramidista, joka on monelle tuttu mutta yhä alihyödynnetty konsepti. Pyramidin pohjalla ovat nopeat yksikkötestit, keskellä integraatiotestit ja huipulla UI-testit. Ongelma ei ole pyramidin tunteminen, vaan sen soveltaminen käytännössä.
13 antipatternia
1. Yksikkötestejä ilman integraatiotestejä
Tämä on tyypillinen pienissä ja keskisuurissa yrityksissä. Yksikkötestit kattavat bisneslogiikan, mutta integraatiotestit puuttuvat. Seurauksena tietokantatransaktioihin, rajapintoihin ja suorituskykyyn liittyvät ongelmat jäävät havaitsematta. Kapelonis muistuttaa: transaktiot, tietokantatriggerit ja komponenttien väliset sopimukset vaativat aina integraatiotestauksen.
2. Integraatiotestejä ilman yksikkötestejä
Käänteinen ongelma, yleinen isoissa yrityksissä. Perusteluna usein “yksikkötestit ovat ajanhukkaa”. Kapelonis näyttää matematiikalla: 4 moduulin järjestelmässä kaikkien koodipolkujen kattamiseen tarvitaan 12 yksikkötestiä mutta jopa 60 integraatiotestiä. Eikä kukaan kirjoita 60:ta – vaan valitsee “edustavan otoksen”, joka jättää katvealueita. Lisäksi integraatiotestit ovat hitaita ja vaikeita debuggata.
3. Vääriä testejä vääriin paikkoihin
Testipyramidi on suositus, ei laki. Komentorivityökalussa painopiste on yksikkötesteissä, maksupalvelussa integraatiotesteissä, ja web-suunnittelutyökalussa UI-testeissä. Älä kopioi sokeasti toisen projektin testistrategiaa.
4. Väärien asioiden testaaminen
Kaikki koodi ei ole samanarvoista. Keskity testaamaan kriittistä toiminnallisuutta – verkkokaupassa ostoskori on tärkeämpi kuin suosittelumoottori. Älä tuhlaa aikaa triviaalien getter/setter-testien kirjoittamiseen.
5. Sisäisen implementaation testaaminen
Testaa käyttäytymistä, älä implementaatiota. Kun testi tietää liikaa koodin sisäisestä rakenteesta, refaktorointi rikkoo testit vaikkei toiminnallisuus muutu. Tämä on yksi yleisimmistä syistä miksi testit hylätään ajan myötä.
6. Liiallinen testikattavuuden tuijottaminen
100 % koodikattavuus ei takaa bugitonta sovellusta – se takaa vain että jokainen rivi on suoritettu testissä. Laatu > määrä. Kapelonis varoittaa erityisesti siitä, miten kattavuusprosentin pakottaminen johtaa arvottomiin testitapauksiin.
7. Epävakaat tai hitaat testit
Flaky testit tuhoavat luottamuksen testiputkeen. Kun sama testi vuoroin onnistuu ja epäonnistuu ilman koodimuutoksia, kehittäjät alkavat ignoroida testejä. Panosta testien deterministisyyteen ja nopeuteen – hidasta testiä ei ajeta, ja epävakaata ei uskota.
8. Manuaalinen testien ajaminen
Jos testit vaativat ihmistä painamaan nappia, niitä ei ajeta. Automaatio on testauksen selkäranka – CI/CD-putkeen integroidut testit ajetaan jokaisella commitilla.
9. Testikoodin kohteleminen toisen luokan kansalaisena
Testikoodi on tuotantokoodia. Se ansaitsee saman huolenpidon: koodikatselmoinnit, refaktoroinnin, dokumentaation. Huono testikoodi on teknistä velkaa yhtä lailla kuin huono tuotantokoodi.
10. Tuotantobugien muuntamatta jättäminen testeiksi
Jokainen tuotannossa havaittu bugi on mahdollisuus parantaa testikattavuutta. Kirjoita aina regressiotesti korjauksen yhteydessä – sama bugi ei saisi päästä tuotantoon kahdesti.
11. TDD:n kohteleminen uskontona
Test-Driven Development on työkalu, ei dogmi. Kapelonis muistuttaa että TDD toimii joissain konteksteissa erinomaisesti, toisissa ei. Älä pakota sitä joka tilanteeseen.
12. Testien kirjoittaminen ilman dokumentaation lukemista
Ennen kuin kirjoitat testin, ymmärrä mitä testaat. Dokumentaatio – olipa se sitten speksi, API-kuvaus tai käyttäjätarina – kertoo miten järjestelmän kuuluu toimia. Ilman tätä ymmärrystä testaat olettamuksia, et todellisuutta.
13. Testauksen mustamaalaaminen tietämättömyyden vuoksi
“Testaus on hidasta”, “testit eivät löydä oikeita bugeja”, “ei meillä ole aikaa testata”. Nämä ovat merkkejä siitä että testaus on tehty huonosti, ei siitä että testaus on hyödytöntä. Hyvä testaus nopeuttaa kehitystä, ei hidasta sitä.
Miksi tällä on merkitystä Suomessa?
Suomalaisessa testauskentässä nämä antipatternit ovat arkipäivää. Näen usein projekteja joissa joko testataan liian vähän tai testataan vääriä asioita. Erityisesti antipatternit 1, 2 ja 7 toistuvat: joko integraatiotestit puuttuvat kokonaan, tai testisetti on niin hidas ja epävakaa ettei kukaan luota siihen.
Kapelonis’n artikkeli on vuodelta 2018, mutta se on ajankohtaisempi kuin koskaan. Mikropalveluiden, AI-pohjaisen testauksen ja jatkuvan toimituksen maailmassa nämä perusperiaatteet ovat entistä tärkeämpiä.
Yhteenveto
Testauksen antipatternit eivät ole merkki epäonnistumisesta – ne ovat merkki siitä että organisaatio ylipäätään testaa. Tärkeintä on tunnistaa nämä sudenkuopat ja pyrkiä jatkuvasti parempaan. Kuten Kapelonis toteaa: kyse ei ole täydellisyydestä, vaan siitä että testit tuottavat aitoa arvoa.
Lähde: Kostis Kapelonis, Software Testing Anti-patterns (2018). Löydetty Hacker Newsin kautta, jossa artikkeli keräsi 465 ääntä ja 166 kommenttia.
Leave a Reply