Brug tests som dokumentation

Start med kravet

Tests dokumenterer konkrete påstande. En vellykket testkørsel dokumenterer ikke alle egenskaber ved softwaren. Før du beder om tests, skal du finde den vigtige adfærd og den fejl, hver kontrol skal opdage.

I en fiktiv organisationseksport er hovedkravet dataisolation. En bruger i organisation A må ikke modtage poster fra organisation B. En test, der kun kontrollerer en vellykket download, dokumenterer ikke dette krav.

Bed agenten om at forklare forholdet mellem kravet og testens assertion. Det gør manglende tilfælde lettere at finde, før testsamlingen bliver stor.

Vælg det passende testomfang

En unit-test kan hurtigt kontrollere en lille transformation. En integrationstest kan kontrollere, hvordan komponenter fungerer sammen. En end-to-end-test kan kontrollere en vigtig brugerhandling gennem den udrullede applikation eller et repræsentativt miljø.

Brug det snævreste omfang, der giver den nødvendige dokumentation. En formatter behøver ikke en fuld browsertest for hvert input. En rettighedsgrænse kan kræve en virkelig route og dataadgang. En kritisk browserhandling kræver dokumentation fra den renderede brugergrænseflade.

Ingen fast procentfordeling mellem testtyper passer til alle systemer. Vælg ud fra den fejl, du skal opdage, og omkostningen ved at vedligeholde kontrollen.

Undgå en fælles forkert antagelse

En agent kan skrive implementering og tests ud fra den samme misforståelse. De kan stemme overens, selv om kravet ikke er opfyldt.

Antag, at implementeringen filtrerer poster efter det organisations-ID, der gives i forespørgslen. Testen bruger det samme ID for den indloggede bruger og forespørgslen. Den består. Det manglende tilfælde er en bruger, der anmoder om en anden organisations ID.

Tilføj tilfældet gennem systemets faktiske betroede identitet og rettighedskontrol. En mock, der altid returnerer »tilladt«, kan ikke dokumentere tenant-isolation. Den dokumenterer kun adfærd, efter at rettighedskontrollen har givet adgang.

Kontrollér, at testen kan fejle

For en kendt fejl skal du køre den nye regressionstest mod den fejlbehæftede version på en isoleret branch. Bekræft, at den fejler af den tilsigtede grund. Anvend derefter rettelsen, og kør testen igen.

En test, der fejler, fordi testdata ikke kan indlæses, dokumenterer endnu ikke forretningsadfærden. Undersøg fejlen, ikke kun exitkoden.

Ved større ændringer kan mutationstest hjælpe med at vurdere, om udvalgte kodeændringer får tests til at fejle. Det har en omkostning og erstatter ikke gennemgang af krav. Brug det, hvor den ekstra dokumentation støtter en beslutning med væsentlige konsekvenser.

Knyt dokumentationen til ændringen

Kør de relevante kontroller på den endelige revision. Registrér udeladte kontroller og begrundelserne. Et resultat fra et tidligere commit gælder måske ikke længere efter en rettelse fra review.

Hold tests forståelige. Foretræk tydelig opsætning og assertion frem for en stor hjælpefunktion, der skjuler den vigtige betingelse. Fjern overflødige kontroller, når de øger vedligeholdelsen uden at opdage en anden fejl.

Revieweren skal kunne forklare, hvad testene dokumenterer, og hvad der stadig er usikkert. Den forklaring er mere nyttig end et stort antal tests.