Använd tester som underlag

Börja med kravet

Tester ger underlag för specifika påståenden. En godkänd testkörning fastställer inte alla egenskaper hos programvaran. Identifiera beteendet som spelar roll och felet varje kontroll ska upptäcka innan du begär tester.

För en fiktiv organisationsexport är huvudkravet dataisolering. En användare i organisation A får inte ta emot poster från organisation B. Ett test som bara kontrollerar lyckad nedladdning fastställer inte detta krav.

Be agenten förklara relationen mellan kravet och assertionen. Det gör saknade fall lättare att upptäcka innan testsviten blir stor.

Välj rätt testomfång

Ett enhetstest kan snabbt kontrollera en liten omvandling. Ett integrationstest kan kontrollera komponenters samverkan. Ett end-to-end-test kan kontrollera en viktig användarsekvens genom den driftsatta eller en representativ applikation.

Använd minsta omfång som ger nödvändigt underlag. En formatterare behöver inte ett fullständigt webbläsartest för varje indata. En auktoriseringsgräns kan behöva en verklig route och dataåtkomstväg. En kritisk webbläsarinteraktion behöver underlag om det renderade gränssnittet.

Ingen fast fördelning av testtyper passar alla system. Välj utifrån felet du behöver upptäcka och kostnaden för att underhålla kontrollen.

Undvik ett gemensamt felaktigt antagande

En agent kan skriva implementation och tester utifrån samma missförstånd. Båda kan stämma överens medan kravet förblir ouppfyllt.

Anta att implementationen filtrerar poster efter organisations-ID:t i förfrågan. Testet använder samma ID för inloggad användare och förfrågan. Det godkänns. Det saknade fallet är en användare som begär en annan organisations ID.

Lägg till fallet genom den faktiska betrodda identiteten och auktoriseringsvägen. En mock som alltid returnerar ”tillåtet” kan inte fastställa isolering mellan klientorganisationer. Den fastställer bara beteende efter lyckad auktorisering.

Verifiera att testet kan misslyckas

Kör ett nytt regressionstest för ett känt fel mot den felaktiga versionen i en isolerad branch. Bekräfta att det misslyckas av avsett skäl. Tillämpa sedan rättningen och kör igen.

Ett test som misslyckas eftersom testdata inte kan laddas ger ännu inget underlag om affärsbeteendet. Granska felet, inte bara exitkoden.

För bredare ändringar kan mutationstestning hjälpa att bedöma om valda kodändringar orsakar testfel. Den kostar resurser och ersätter inte kravgranskning. Använd den där det extra underlaget stöder ett beslut med betydande konsekvenser.

Håll underlaget kopplat till ändringen

Kör relevanta kontroller på slutlig revision. Anteckna överhoppade kontroller och orsaker. Ett resultat från en tidigare commit kan vara inaktuellt efter en granskningsrättning.

Håll tester begripliga. Föredra uttrycklig uppsättning och assertion framför en stor hjälpfunktion som döljer det viktiga villkoret. Ta bort överflödiga kontroller som ökar underhållskostnaden utan att upptäcka ett annat fel.

Granskaren ska kunna ange vad testerna visar och vad som är osäkert. Förklaringen är mer användbar än ett stort antal tester.