Skrive tester

Den enkleste testen er et program som kaster en feil hvis noe er galt. Du trenger ikke et rammeverk for å komme i gang.

funksjon krev(navn: tekst, faktisk: boolsk) {
    hvis faktisk {
        skriv("test(" + navn + ", ok)")
    } ellers {
        skriv("test(" + navn + ", FEIL)")
        kast "testen feilet: " + navn
    }
}

funksjon summer(tall: liste_heltall) -> heltall {
    la sum = 0
    for verdi i tall {
        sum = sum + verdi
    }
    returner sum
}

funksjon start() -> heltall {
    krev("tom_liste", summer([]) == 0)
    krev("ett_tall", summer([5]) == 5)
    krev("flere_tall", summer([1, 2, 3]) == 6)
    krev("negative", summer([-2, 2]) == 0)
    skriv("alle testene passerte")
    returner 0
}

Hva som skjer her

krev skriver én linje per påstand og kaster hvis noe ikke stemmer. Det gir deg to ting gratis: du ser hvilke påstander som ble kjørt, og kjøringen stopper med feilkode på den første som ryker. Et byggeskript merker det uten at du trenger å tolke utdata.

At hver påstand har et navn er viktigere enn det ser ut. Når testen feiler om tre måneder, er navnet det eneste du har å gå etter. krev("negative", ...) forteller deg med en gang hva som er brutt; krev("test4", ...) sender deg tilbake til å lese koden.

Test grensene, ikke midten

Dette er det viktigste rådet i hele oppskriften.

At summer([1, 2, 3]) gir 6 er nesten aldri der feilen sitter. Den testen ville passert selv med ganske gal kode. Feilene bor et annet sted:

• Den tomme lista. Hva returnerer funksjonen når det ikke er noe å summere? Mange implementasjoner krasjer eller returnerer noe tilfeldig.
• Ett element. Grensen mellom ingenting og noe er der løkker ofte teller feil.
• Negative tall. Antakelser om at alt er positivt er vanlige og usagte.
• Rett over og under en terskel. Har koden en grense ved hundre, test 99, 100 og 101.

Skriv de testene først. De vanlige tilfellene kan du legge til etterpå.

La testen feile først

En test som aldri har feilet, har ikke bevist noe. Den kan være skrevet slik at den passerer uansett.

Vanen er enkel: bryt koden med vilje — bytt et pluss mot et minus — og se at testen faktisk sier fra. Deretter retter du tilbake. Det tar ti sekunder og skiller en test som beskytter deg fra en som bare ser betryggende ut.

Kjør dem

nc run test_summer.no

Standardbiblioteket har også std.test og std.unittest når du vil ha mer struktur, og std.mock_http for å teste kode som snakker med nettet uten å faktisk gjøre det. Men mønsteret over — en funksjon som kaster, og en liste med navngitte påstander — bærer overraskende langt.

Tilbake til oversikten