TDD i praksis for nybegynnere: slik skriver du tester før koden uten å gå deg vill

Mange hører at «du burde bruke TDD» og nikker høflig, men sitter igjen og lurer på hva det faktisk betyr i hverdagen. Testdrevet utvikling høres teoretisk ut, men kan bli et veldig konkret verktøy for å tenke klarere og skrive renere kode.

I denne artikkelen går vi steg for steg gjennom hvordan du kan komme i gang med TDD på en jordnær måte. Vi bruker et lite, realistisk kodeeksempel og ser på hvordan tankesettet rundt tester hjelper deg å ta bedre valg underveis.

Hva er TDD, egentlig?

TDD står for testdrevet utvikling. I stedet for å skrive kode først og tester etterpå, snur du rekkefølgen: du starter med å skrive en liten test som beskriver hva koden skal gjøre, så skriver du akkurat nok kode til at testen går gjennom.

Dette skjer i en kort syklus som ofte oppsummeres som:Red → Green → Refactor. Navnene kommer fra fargene du typisk ser i testverktøyet ditt når en test feiler (rød) eller passerer (grønn).

Red, Green, Refactor: den lille sirkelen som styrer alt

Red:Du skriver en test som feiler, fordi funksjonen eller oppførselen ikke finnes ennå. Dette tvinger deg til å være tydelig på hva du egentlig forventer av koden.

Green:Du skriver den enkleste mulige implementasjonen som får testen til å passere. Ikke pen, ikke generell, bare nok til å bli grønn.

Refactor:Når testen er grønn, kan du trygt rydde i koden. Du forbedrer struktur, navn og duplisering, mens testene sjekker at oppførselen fortsatt er riktig.

Et konkret eksempel: rabattkalkulator i Python

La oss si at du skal lage en liten funksjon som beregner pris etter rabatt. Kravene er omtrent slik: du har en originalpris og en rabatt i prosent, og du vil ha sluttprisen avrundet til to desimaler. Maks rabatt skal være 80 prosent, alt over det skal behandles som 80.

Vi bruker Python for å holde eksemplet kort, men prinsippene er de samme i andre språk. Eksemplet er for læring, så ikke bruk det direkte i produksjon uten å tilpasse det til dine behov og sikkerhetskrav.

Steg 1: Red – skriv en første test

Vi starter med den enkleste situasjonen: ingen rabatt. I filentest_rabatt.pyskriver du:

Merk:Hvis du ikke har brukt pytest før, kan du lese dokumentasjonen og tilpasse oppsettet til systemet ditt.

def test_beregner_full_pris_uten_rabatt():
    from rabatt import beregn_pris_etter_rabatt
    resultat = beregn_pris_etter_rabatt(100, 0)
    assert resultat == 100.00

Når du kjører testen, vil den feile fordirabatt.pyog funksjonen ikke finnes ennå. Det er helt riktig og forventet i TDD.

Steg 2: Green – skriv minimal kode

Nå lager du filenrabatt.pymed den enkleste implementasjonen som får testen grønn:

def beregn_pris_etter_rabatt(pris, rabatt_prosent):
    return 100.00

Dette er åpenbart ikke generelt riktig, men det er nok til å få den første testen grønn. Poenget er ikke å være smart på første forsøk, men å jobbe i små, trygge steg.

Utvid kravene steg for steg med nye tester

Nå legger du til flere tester som presiserer oppførselen. Hver test beskriver en ny regel eller et nytt hjørnetilfelle, og du forbedrer koden akkurat nok til at alle tester består.

Legg til følgende itest_rabatt.py:

def test_beregner_pris_med_10_prosent_rabatt():
    from rabatt import beregn_pris_etter_rabatt
    resultat = beregn_pris_etter_rabatt(200, 10)
    assert resultat == 180.00

Nå feiler testen, så du oppdaterer funksjonen:

def beregn_pris_etter_rabatt(pris, rabatt_prosent):
    rabatt_belop = pris * (rabatt_prosent / 100)
    sluttpris = pris - rabatt_belop
    return round(sluttpris, 2)

Kjør testene igjen. Begge testene bør nå være grønne. Deretter kan du fortsette å stramme inn kravene.

Flere regler: maks rabatt og avrunding

La oss si at du vil hindre «negativ pris» på grunn av for høy rabatt. Du skriver først en test som beskriver ønsket oppførsel:

def test_begrenser_rabatt_til_maks_80_prosent():
    from rabatt import beregn_pris_etter_rabatt
    resultat = beregn_pris_etter_rabatt(100, 90)
    assert resultat == 20.00

Nå må funksjonen håndtere maks rabatt:

def beregn_pris_etter_rabatt(pris, rabatt_prosent):
    if rabatt_prosent > 80:
        rabatt_prosent = 80

    rabatt_belop = pris * (rabatt_prosent / 100)
    sluttpris = pris - rabatt_belop
    return round(sluttpris, 2)

Ved å la testen styre endringen, unngår du å overtenke løsningen. Du fokuserer på én konkret regel om gangen.

Refactor: når testene er grønne, kan du rydde

Når alle tester er grønne, har du et sikkerhetsnett. Nå kan du forbedre koden uten å være like redd for å ødelegge noe. For eksempel kan du trekke ut kontrollen for rabattgrense i en egen liten funksjon, eller gi bedre navn på variabler.

Et viktig poeng i TDD er at du ikke skal «rydde» midt i rød fase. Vent til alt er grønt, så blir det mye enklere å se hva som faktisk forbedrer koden og hva som introduserer nye feil.

Typiske misforståelser om TDD

Mange tror at TDD betyr at du må skrive tester for absolutt alt, eller at du aldri kan endre krav underveis. I praksis er det mer fleksibelt: TDD er først og fremst et verktøy for å tenke i små steg og gjøre forventningene eksplisitte.

En annen vanlig misforståelse er at TDD bare passer for store, komplekse systemer. I virkeligheten er det ofte mest lærerikt på små funksjoner og tjenester, der du tydelig ser hvordan testene former designet.

Slik kommer du i gang med TDD i ditt eget prosjekt

Du trenger ikke «gå all in» fra dag én. Start i det små, med deler av koden der du ofte gjør feil eller føler deg usikker. Velg én funksjon, skriv en test først, og øv på Red → Green → Refactor.

Over tid kan du:

• Plukke ut nye funksjoner der du konsekvent starter med test.
• Bruke tester til å beskrive feil du nettopp har funnet, før du retter dem.
• La testene være dokumentasjon på hvordan API-er og moduler skal brukes.

Det viktigste er ikke å følge en streng oppskrift, men å bruke TDD som et hjelpemiddel for klarere tankegang, tryggere endringer og mer forutsigbar kode.