Hvorfor vi skal droppe automatiske tester

Hvis vi går tilbake noen år var det svært vanlig å drive såkalt testdrevet utvikling. Testene skulle skrives først, så koden som fikk testene til å passere.

På den måten skulle du tvinges til å tenke gjennom alle scenarier som skulle oppstå, blant annet ved at hjørnetilfeller kom frem i lyset så fort som mulig.

Mange av oss fikk dette inn, om ikke med morsmelken, så enten i starten av karrieren, eller som en av mange introduksjoner til programmering når vi var på ett av mange programmeringskurs noen år tilbake. Et av de mest populære eksemplene var Uncle Bobs Bowling Kata

Man kan argumentere for at dette hadde sin verdi når det gjelder å løse et helt spesifikt problem med rigide regler.

Å kjøre samme tilnærming på et avgrenset område, f.eks. beregning av helligdager eller virkedager, kan vi på samme måte se nytten,
men når det gjelder størstedelen av produktene vi arbeider med dag-til-dag, er å skrive tester først kanskje ikke den beste tilnærmingen.

Mer unntaket enn regelen har vi ikke helt klart for oss hva vi skal lage, og i alle fall ikke hvordan det skal implementeres.

For oss som var med på større prosjekter var det også vanlig med verktøy som Sonar eller Jacoco som automatisk målte testdekning, der det gjerne var et krav om at dette skulle ha en viss, gjerne svært høy prosentandel av koden som var skrevet.

Konsekvensen var ofte at man skrev tester som i seg selv ga liten verdi, men testet kode som hittil var utestet, og ga uttelling på testrapporter.

Siden vi stort sett har beveget oss i mer smidig retning, hvor så hyppige produksjonssettinger som mulig er et uttalt mål, er naturlig nok også koden som blir lagt ut til brukere langt mindre i volum. Det vil derfor være kort vei til å kunne rette eventuelle feil som blir oppdaget i miljøet der de reelle brukerene tross alt oppholder seg.

Tester trenger også vedlikehold som alt annet. Det er ikke bare selve kodebasen man må forholde seg til, hver eneste bygging på utviklermaskinen vil typisk kjøre samtlige tester for å forsikre utvikler om at alt fortsatt er i vater.

Vi bygget nettopp en helt ny applikasjon der vi droppet å skrive en eneste test. Under utvikling opplevde jeg sjelden som utvikler at jeg var usikker på om det jeg hadde endret på ville føre til utilsiktede endringer.

Det skal sies at applikasjonen vi laget var forholdsvis enkel, med få krav til ytelse og skalering. Vi endte med en backend med noen få REST-endepunkter, og et funksjonelt språk til frontenden. Det var aldri et prinsipp for oss ikke å ha tester. Hadde vi sett verdien av det hadde vi innført tester der det var behov for umiddelbart.

Til nå har vi, bank i bordet, ikke fått noen feilrapporter fra første prodsetting.

En av de viktigste grunnene til å ha tester, er at en utvikler skal kunne være trygg på at endringene hennes ikke fører til sideeffekter.

Det vi har funnet ut har vært verdifullt på vårt prosjekt, har vært å fokusere på å teste applikasjoners oppførsel.
Finn ut hva som er det mest kritiske for din applikasjon og begynn der. Tilbyr applikasjonen betaling, begynn med å teste at den viktigste funksjonaliteten fungerer som den skal. At ordrenummer, varenummer, betalingsreferanser o.l. faktisk ikke lager kjipe
situasjoner for brukerne er en selvfølge å få avdekket tidlig i utviklingsprosessen, men skal også sørge for at de som utvikler applikasjonen skal få en god forståelse av systemet.

Mye av den helt vanlige vaniljefunksjonaliteten til en applikasjon er derimot ofte såpass rett frem at man kanskje ikke trenger all verdens tester.

Som med alt annet blir også dette en kost/nytte - vurdering. Som utvikler bør du begynne med det som er mest sårbart og kritisk, eller det som åpner for at andre utviklere kan trå feil.

Merk her at jeg bare snakker om automatiske tester. Brukertesting, sikkerhetstesting, og ytelsestesting blir en helt annen skål!

Det er ofte en god ting å slette kode når man er inne i refaktorering av en applikasjon, tester burde heller ikke være fredet.