Tester er dokumentasjon
Av Roger H. Pedersen
Jeg har ikke mange kjepphester i programvareutvikling. Men kodete tester er en.
Det finnes hvert fall en bok og sikkert to artikler på internett om hvordan du bør teste, hvilke typer tester du skal ha og hvor mange av typene. Hvordan koden bør struktureres og så bortetter.
Dette blir den tredje artikkelen (ikke verifisert).
Her går jeg gjennom hvorfor jeg skriver tester og hvordan jeg gjør det. Utgangspunktet er en webapp som tilbyr et api. Det er et vanlig scenario.
I hovedsak har jeg to typer tester:
Api-/integrasjonstester
Her testes funksjonaliteten fra en klients ståsted.
Jeg ønsker å mocke minst mulig. Samme type database som brukes i produksjon, men tredjepartsapier er mocket. Det er viktig å ha alltid ha kontroll på tilstand for konsistens for at tester skal kunne kjøres overalt og når som helst. Tredjeparter gjør det vanskelig, så mock dem for ulike caser.
Hver test seeder databasen og eventuelle tredjepartsmocker med de data som er nødvendig for å gjennomføre testen.
Det er en teknisk gevinst med slike tester også. De viser at applikasjonen faktisk starter opp hele rakleverket med all DI, konfigurasjon og at middlewares m.m. virker.
Disse testene er forholdsvis tunge og tidkrevende å sette opp og tidkrevende (alt er relativt) å kjøre. Her begrenser jeg meg stort sett til å teste hovedflyten.
Unittester
Ingenting spesielt her. Hver funksjon testes isolert med ulike inputs og resultatet verifiseres. Avhengigheter mockes.
Disse kan det bli en del av, men er forholdsvis kjappe å sette opp og kjører lynraskt.
Så hva gir disse testene meg?
Testene "beviser" at jeg leverer funksjonalitet som virker.
Testene er dokumentasjon og ingenting er bedre(ikke verifisert) enn å dokumentere med kode heller enn med dokumenter og lignende som er utdatert før du får publisert dem. Verden har nok utdaterte wikisider(verifisert).
Testene gjør veien kort når man trenger å gjenskape en produksjonsfeil.
Tester "beviser" at jeg leverer funksjonalitet som virker
Alle, ok, utviklere da, kan kjøre koden min vhja testene og se at funksjonen faktisk virker. De kan også se at testene dekker de funksjonelle kravene.
Det kan alltid oppstå uforutsette ting. Det er en brannmur i produksjonsmiljøet, et api leverte ikke i henhold til kontrakten og en mengde andre ting. Derfor tester jeg alltid selv i produksjon så langt det lar seg gjøre. Og skulle jeg oppdage en bug så har jeg tester for å gjenskape buggen. Da slipper jeg at brukeren av funksjonaliteten rapporterer en bug rett før middag.
Tester er dokumentasjon
Apitestene viser en utvikler hvilken tilstand som er påkrevd i f.eks. databasen eller tredjepart for at noe funksjonalitet skal virke. I tillegg har jeg forventninger til hvordan resultatet etter at testen er kjørt skal se ut.
Unittestene går mer i dypden med en mengde ulike inputs og forventninger til resultatet. Resultatet kan være sideeffekter. Husk å verifisere at disse blir utført.
Mens apitestene gjerne heter "CreateCustomerOk", så heter unitestene "FailIfDuplicateCustomer", "FailIfCustomerConditionIsNotValid", "CustomerWithSuchPropertyShouldTriggerExternalApi" osv.
Med mindre du jobber på ditt eget hobbyprosjekt så er det aldri din kode. Det er alltid koden til den neste utvikleren. Derfor må du sette vedkommende i stand til å vedlikeholde, videreutvikle og bugfikse koden du har laget.
Skulle noen knekke din funksjonalitet uten at testene avdekker det så er den "noen" deg.
Testene gjør veien kort når man trenger i gjenskape en produksjonsfeil
Det er ganske deilig(verifisert) å bare sette opp den lokale databasen (eller tredjepartsmocken) og kjøre med samme input som skapte trøbbel i produksjon. Se resultatet og debugge i ro og mak.
Eller sette opp unittesten med en input/output som "garantert aldri vil oppstå" og deretter endre kode og tester slik at funksjonen virker i dette tilfellet også.
Utviklingstid bør ikke bare måles i tiden det tar å utvikle og produksjonsette funksjonalitet, men også inkludere vedlikehold og tiden det tar å bugfikse.
Tips til slutt. Bruk for eksempel et verktøy som https://testcontainers.com/. Så har du infrastrukturen som kode også og det er enda lettere å komme i gang med onboarding.