Gebruik tests als bewijs

Begin met de eis

Tests zijn bewijs voor specifieke beweringen. Een geslaagde testrun toont niet elke eigenschap van de software aan. Identificeer vóór het aanvragen van tests het relevante gedrag en het defect dat elke controle moet ontdekken.

Voor een fictieve organisatie-export is gegevensisolatie de belangrijkste eis. Een gebruiker in organisatie A mag geen records uit organisatie B ontvangen. Een test die alleen een geslaagde download controleert, toont dit niet aan.

Vraag de agent de relatie tussen eis en assertion uit te leggen. Zo zijn ontbrekende gevallen makkelijker te vinden voordat de testsuite groot wordt.

Kies de passende testscope

Een unittest kan snel een kleine omzetting controleren. Een integratietest kan controleren hoe componenten samenwerken. Een end-to-endtest kan een belangrijke gebruikersreeks door de gedeployde of representatieve applicatie controleren.

Gebruik de kleinste scope die het vereiste bewijs oplevert. Een formatter heeft niet voor elke invoer een volledige browsertest nodig. Een autorisatiegrens kan een echte route en toegangspad tot data nodig hebben. Een kritieke browserinteractie vraagt bewijs over de gerenderde interface.

Geen vast percentage testtypen past bij elk systeem. Kies op basis van het defect dat u moet ontdekken en de onderhoudskosten van de controle.

Vermijd een gedeelde onjuiste aanname

Een agent kan implementatie en tests vanuit hetzelfde misverstand schrijven. Beide kunnen overeenstemmen terwijl de eis onvervuld blijft.

Stel dat de implementatie records filtert op het organisatie-ID uit het verzoek. De test gebruikt hetzelfde ID voor de ingelogde gebruiker en het verzoek. De test slaagt. Het ontbrekende geval is een gebruiker die het ID van een andere organisatie opvraagt.

Voeg dat geval toe via de werkelijke vertrouwde identiteit en het autorisatiepad. Een mock die altijd ‘toegestaan’ teruggeeft, kan tenantisolatie niet aantonen. Die toont alleen gedrag aan nadat autorisatie is geslaagd.

Verifieer dat de test kan falen

Voer bij een bekend defect de nieuwe regressietest uit op de defecte versie in een geïsoleerde branch. Bevestig dat de test om de bedoelde reden faalt. Pas daarna de correctie toe en voer de test opnieuw uit.

Een test die faalt doordat testdata niet kunnen worden geladen, is nog geen bewijs over het bedrijfsproces. Inspecteer de fout, niet alleen de exitcode.

Bij bredere wijzigingen kan mutation testing helpen beoordelen of bepaalde codewijzigingen testfouten veroorzaken. Dit kost inspanning en vervangt geen beoordeling van eisen. Gebruik het waar extra bewijs een besluit met belangrijke gevolgen ondersteunt.

Houd het bewijs gekoppeld aan de wijziging

Voer de relevante controles uit op de laatste revisie. Noteer overgeslagen controles en hun redenen. Een resultaat van een eerdere commit geldt mogelijk niet meer na een reviewcorrectie.

Houd tests begrijpelijk. Kies liever een expliciete setup en assertion dan een grote helper die de belangrijke voorwaarde verbergt. Verwijder overbodige controles als ze onderhoud kosten zonder een ander foutgeval te ontdekken.

De reviewer moet kunnen aangeven wat de tests aantonen en wat onzeker blijft. Die uitleg is nuttiger dan een groot testaantal.