div

Som sagt står vi fritt til å velge hvordan vi skriver ned testene. Her er noe av det vi liker med formatet vi valgte i testsamlingen for handlelisten:

•Testene har en ID. Dette gjør det lett å snakke om testene med andre, for eksempel kan vi si at «Testtilfelle #1 feilet». • Testene har navn som beskriver hva målet med akkurat denne testen er. Da blir det lett for folk å forstå hva vi ønsker å teste. Jo større testsamlingen er, desto nyttigere er det å ha gode navn på testene. • Det er tydelig hva som er instrukser, og hva som er forventede resultater.

Det er tydelig hva som skal gjøres, og hva som er de forventede mellom- og sluttresultatene. • Vi har lagt ved et bilde av sluttresultatet. Dette burde bidra til å avklare eventuelle utydelige instruksjoner.

EKSTRASTOFF

Tenke som en motstander

Når du skal skrive tester for realistiske tilfeller, kan det være nyttig å tenke som en motstander som prøver så godt han kan å ødelegge programmet ditt. En slik motstander kunne for eksempel ha funnet på å gjøre følgende: • skrive inn en veldig lang streng i input-feltet, for eksempel lime inn en hel avisartikkel • la strengen inneholde forskjellige tegn, som norske bokstaver, bokstaver med aksenter (for eksempel é, à eller ö) eller emojier • la være å skrive inn noe • klikke på helt andre knapper enn «Lagre»- og «Avbryt»-knappen etter at han har redigert innholdet • lime inn tekst på andre skriftspråk, for eksempel arabisk, kinesisk eller gresk • prøve å lime inn et bilde i input-feltet Når du har skrevet ned alt en motstander kunne ha gjort for å ødelegge programmet, tar du stilling til om du synes det er verdt å lage tester som prøver ut disse punktene. Mye av det som står på listen ovenfor, er rimelig å teste: • Noen matvarer har rare tegn i navnet, som crème fraîche. • Brukere gjør feil, som å lagre tomme verdier. • Folk liker å bruke emojier. • Hvis brukerne blir distrahert, kan de fort glemme at de holdt på å redigere navnet på én vare og klikke på pluss- og minusknappen for en annen vare. Når det gjelder handlelisten, har vi allerede tatt hensyn til de to første punktene ovenfor i testtilfelle #2. De to siste punktene har vi ikke tatt hensyn til. Selv forslag som kan virke urimelige ved første øyekast, kan være verdifulle. Det virker for eksempel urimelig at programmet skal tåle at brukerne limer inn en hel avisartikkel. Men brukere kan jo lime inn lange strenger uten at de har til hensikt å ødelegge noe. En bruker kan for eksempel ha prøvd å kopiere én ingrediens fra en lengre matoppskrift og ved en feil ha kopiert hele matoppskriften. Dermed kan det være lurt å teste om programmet tåler det, slik at brukeren kan rette opp i feilen etterpå. Noen forslag kan vi overse med god samvittighet. De fleste nettlesere nekter å lime inn bilder i tekstfelter, så det er unødvendig å teste dette. Hvis vi lager en handleliste med norsk brukergrensesnitt, klarer brukerne seg sannsynligvis uten arabiske og kinesiske tegn.

DISKUTER

Synes du at disse testene dekker alt det er naturlig å bruke handlelisten til? Er det noe du burde ha lagt til? Er det for eksempel noen knapper som det ikke er klikket på?

EKSTRASTOFF

Det er lurt å skrive testene før koden

I dette delkapittelet har vi testet kode som vi allerede har skrevet. Det er god praksis å skrive testene før vi skriver koden. Når vi skriver testene etter at koden ferdig, er det flere menneskelige faktorer som gjør at kvaliteten på testene blir dårligere, blant annet: • Vi har ikke lyst til å finne feil i noe vi allerede har lagt mye arbeid i. Derfor har vi lett for å forhaste oss, og vi tar ikke oppgaven med å tenke som en motstander på alvor. • Testingen virker som unødvendig ekstraarbeid: Vi eksperimenterte jo mens vi laget programmet, og det må da være godt nok. Andre oppgaver haster, og det er fristende å droppe testingen, slik at vi kan begynne på dem. • Vi er sliten og lei av oppgaven som vi har holdt på med en stund nå. Vi har ikke overskudd til å skrive like gode tester som vi hadde gjort dersom vi hadde skrevet dem før vi begynte på oppgaven. Hvis vi skriver testene, eller et utkast til dem, på forhånd, klarer vi sannsynligvis å komme på flere av forventningene en ny bruker møter nettsiden eller programmet med, og vi tar arbeidet mer alvorlig. Å skrive testene trenger ikke å ta mer enn noen få minutter. Det er ikke nødvendig å skrive ned alle stegene og få med alle kravene med en gang. Det er heller ikke sikkert at alle kravene til programmet er klare før vi har jobbet litt med det. Det viktigste er at vi gjør så mye vi kan, slik at vi kan forbedre testene etter hvert. Det er ingen som forventer at du som er elev alltid skal skrive tester på forhånd. Det er helt greit at du skriver tester etter at du har skrevet koden. Når du har fått mer erfaring, kan du prøve deg litt frem. Du kan for eksempel skrive en test før du legger til en ny knapp i et eksisterende program.

2.5 Feilsøking

Feilsøking handler om å finne ut hvorfor et resultat ikke er som forventet. Med mindre du har rettet opp i handleliste-koden, feilet begge testene i forrige delkapittel. Når vi klikker på «Legg til vare» og pluss- og minusknappene, tilbakestilles navnene på de tidligere varene vi har lagt til, men ikke antallet. Dette er en utilsiktet feil som oppsto da vi skrev koden, men som vi har beholdt, slik at vi kunne bruke den til å demonstrere feilsøking.

NOTER DET DU TROR ER FEIL, OG UNDERSØK DET

Det første du bør gjøre når du skal feilsøke, er å skrive ned alt du tror kan være opphav til feilen, i en tekstfil. Da unngår du å miste tråden underveis eller glemme gode ideer. Hvis du må be andre om hjelp, er det veldig nyttig for dem å vite hva du har sett på, og da kan du vise dem tekstfilen. Når du har funnet feilen og løst den, kan du ta vare på filen slik at du kan lære av det du har gjort.