Bruk tester som dokumentasjon

Start med kravet

Tester er dokumentasjon for konkrete påstander. En vellykket testkjøring dokumenterer ikke alle programvarens egenskaper. Identifiser atferden som betyr noe, og feilen hver kontroll bør oppdage, før du ber om tester.

For en fiktiv organisasjonseksport er hovedkravet dataisolasjon. En bruker i organisasjon A må ikke motta poster fra organisasjon B. En test som bare kontrollerer en vellykket nedlasting, dokumenterer ikke dette kravet.

Be agenten forklare forholdet mellom kravet og testpåstanden. Det gjør manglende tilfeller lettere å oppdage før testsamlingen blir stor.

Velg riktig testomfang

En enhetstest kan kontrollere en liten transformasjon raskt. En integrasjonstest kan kontrollere hvordan komponenter fungerer sammen. En ende-til-ende-test kan kontrollere en viktig brukerhandling gjennom den utrullede eller en representativ applikasjon.

Bruk det smaleste omfanget som gir nødvendig dokumentasjon. Et formateringsverktøy trenger ikke en full nettlesertest for alle inndata. En autorisasjonsgrense kan kreve en reell route og datatilgangsvei. En kritisk nettleserinteraksjon trenger dokumentasjon om det rendrerte grensesnittet.

Ingen fast prosentfordeling av testtyper passer alle systemer. Velg ut fra feilen du må oppdage, og kostnaden ved å vedlikeholde kontrollen.

Unngå en felles feil antakelse

En agent kan skrive implementering og tester ut fra samme misforståelse. Begge kan være enige uten at kravet er oppfylt.

Anta at implementeringen filtrerer poster etter organisasjons-ID-en i forespørselen. Testen bruker samme ID for den innloggede brukeren og forespørselen. Den består. Det manglende tilfellet er en bruker som ber om en annen organisasjons ID.

Legg til dette tilfellet gjennom den faktiske betrodde identitets- og autorisasjonsveien. En mock som alltid returnerer «tillatt», kan ikke dokumentere tenantisolasjon. Den dokumenterer bare atferd etter vellykket autorisasjon.

Verifiser at testen kan feile

Kjør den nye regresjonstesten mot versjonen med en kjent feil i en isolert branch. Bekreft at den feiler av tilsiktet årsak. Bruk deretter rettelsen, og kjør testen igjen.

En test som feiler fordi testdata ikke kan lastes inn, er ennå ikke dokumentasjon om forretningsatferden. Undersøk feilen, ikke bare exitkoden.

For bredere endringer kan mutasjonstesting bidra til å vurdere om utvalgte kodeendringer fører til testfeil. Det har en kostnad og erstatter ikke kravgjennomgang. Bruk det der tilleggsdokumentasjonen støtter en vesentlig beslutning.

Hold dokumentasjonen knyttet til endringen

Kjør relevante kontroller på den endelige revisjonen. Registrer kontroller som ble hoppet over, og begrunnelsene. Et resultat fra et tidligere commit gjelder kanskje ikke etter en reviewrettelse.

Hold testene forståelige. Foretrekk tydelig oppsett og testpåstand fremfor en stor hjelpefunksjon som skjuler den viktige betingelsen. Fjern overflødige kontroller når de øker vedlikeholdskostnaden uten å oppdage en annen feil.

Revieweren bør kunne si hva testene dokumenterer, og hva som fortsatt er usikkert. Forklaringen er mer nyttig enn et stort antall tester.