Winst:
- Mogelijkheid om unit-tests, edge-cases en dekkingsgapsanalyses uit te voeren met AI
- Mogelijkheid om testverwachtingen af te drukken op basis van de specificatie, niet op het huidige gedrag van de code
- Mogelijkheid om te testen of een test daadwerkelijk beschermt door fouten te injecteren
Het schrijven van tests is een van de meest waardeproducerende taken die de meeste ontwikkelaars uitstellen. Een goede testsuite is het bewijs dat de code werkt zoals verwacht en een reddingslijn voor toekomstige wijzigingen. Het probleem is dat het schrijven van toetsen repetitief en tijdrovend is – precies het soort werk waarin AI uitblinkt. Maar er zit een addertje onder het gras: AI test vaak het bestaande gedrag van de code, niet het gedrag dat het zou moeten zijn. Het beheren van dit verschil is de essentie van deze unit.
In deze unit leer je unit-testen (testen waarbij een functie afzonderlijk wordt getest), edge case-tests en het genereren van testgegevens met AI; het dichten van gaten in de testdekking; en waarom blindelings vertrouwen op AI-tests gevaarlijk is.
De twee kanten van testen: gedrag corrigeren versus verifiëren
Een test kan twee verschillende doelen dienen. De eerste is verificatie: er wordt getest of de code correct is, of deze voldoet aan de specificatie. De tweede is regressiebescherming: het bevriest het gedrag van de code van vandaag, dus als iemand deze morgen per ongeluk wijzigt, zal de test kapot gaan en een melding sturen.
AI is erg goed in dat laatste; Het kijkt naar de code en genereert cases die testen "wat het nu doet". Maar als de code vanaf het begin verkeerd is, kan AI dat verkeerde gedrag als ‘correct’ bestempelen. Je moet dus de bewering van elke test die de AI produceert herzien: ‘De code retourneert 42 en de test verwacht 42’ betekent niet dat 42 het juiste antwoord is.
Let op: als de AI de test doorstaat, betekent dit niet dat de code "werkt"; het betekent gewoon "het gedraagt zich zoals de AI verwacht". Of de verwachting klopt of niet, bepaal je door naar de specificatie te kijken.
Stap voor stap: robuuste tests schrijven met AI
- Geef de specificatie, niet alleen de code. Als je de informatie toevoegt ‘Deze functie zou dit moeten doen’, kan de AI de juiste verwachting schrijven; Als u alleen de code opgeeft, wordt het huidige gedrag getest.
- Vraag naar randgevallen. Leeg, nul, nul, negatief, te groot, slecht formaat, gelijktijdigheid – claim expliciet buiten het gelukkige pad.
- Specificeer het testframework en de stijl. "gebruik pytest", "Arrange-Act-Assert-patroon", "laat elke test één ding testen" enz.
- Controleer de verwachtingen (bewering). Vergelijk met de specificatie die elke bewering controleert op de juiste waarde.
- Sluit gaten in de reikwijdte. Geef bestaande tests door en vraag "welke branches en cases zijn niet getest?" laat je vragen; controleer vervolgens of er aanvullende tests zijn uitgevoerd.
Drie mini-hoesjes
Geval 1 — Dekking van 52% naar 85%. De testdekking van één servicemodule was 52%. Het team voerde de bestaande tests door naar de AI, liet deze de niet-geteste branches opsommen en er tests voor genereren. Dankzij menselijke beoordeling steeg de dekking tot 85%; Daarbij ontdekte de AI een daadwerkelijke bug (een pad dat de verkeerde foutcode retourneerde) in een bugbranch die nog nooit eerder was getest.
Geval 2 – De valstrik van valse verwachtingen. Een geldafrondingsfunctie was eigenlijk verkeerd; In plaats van 2,675 af te ronden naar 2,67, werd 2,67 afgerond in plaats van 2,68. De AI keek naar de code en schreef assert round_money(2.675) == 2.67 – waarbij de fout als “true” werd bevroren. Toen de ontwikkelaar de specificatie las, corrigeerde hij de verwachting en ontdekte hij de echte bug. Het testen van de regel, en niet van de code, maakte het verschil.
Geval 3 – Explosie van de randtoestand. Bij het vragen aan de AI om alleen ‘edge cases’ voor een datumbereikfunctie; Het leverde 8 gevallen op, zoals start=eind, omgekeerd interval, schrikkeljaar 29 februari, verschillende tijdzones en nulinterval. Twee hiervan (omgekeerde spatiëring en schrikkeljaar) veroorzaakten feitelijk de fout. Het handmatig beoordelen van deze gevallen wordt vaak overgeslagen; AI werd hier een ‘edge-case brainstorming’-partner.
Vier kopieerbare sjablonen
Op specificaties gebaseerde testgeneratie:
Rol: Een ontwikkelaar die tests schrijft. Framework: {{pytest/JUnit/Jest...}}.Wat de functie MOET DOEN (specificatie): {{rule}}Schrijf tests voor de volgende functie. Schrijf verwachtingen volgens de specificatie, NIET de huidige uitvoer van de code. Gelukkig pad + voeg minimaal 4 randgevallen toe. Laat elke test één ding testen, gebruik een beschrijvende naam. {{functie}}
Brainstormen over randgevallen:
Maak een lijst van rand-/foutgevallen die moeten worden geprobeerd bij het testen van deze functie (null, null, breakpoints, slecht formaat, gelijktijdigheid, externe fout). Voor elk geval: invoer, verwacht gedrag. Schrijf nog GEEN code, vermeld gewoon.{{function}}
Analyse van dekkingsverschillen:
Hieronder staan de functies en beschikbare tests. Welke branches, voorwaarden en cases zijn niet getoetst? Maak een lijst van de tekortkomingen en schrijf alleen nieuwe tests voor de tekortkomingen. Herhaal geen bestaande. Functie:{{function}}Tests:{{existing_tests}}
Testgegevens / genereren van nepobjecten:
Genereer realistische testgegevens voor {{function/service}}-tests: geldige monsters, grensmonsters en ongeldige monsters afzonderlijk. Stel een eenvoudig nepgedrag voor voor de externe afhankelijkheid {{X}}. Echt vertrouwelijke gegevens/PII gebruiken; Genereer valse gegevens.
Zwakke prompt/sterke prompt
Zwak: "Schrijf een test voor deze functie."
Sterk: "met pytest. Functie apply_discount(total, percent) - regel: korting moet 0%-30% zijn, buiten de grenzen moet ValueError opleveren, het resultaat moet worden afgerond op 2 decimalen. Schrijf de verwachtingen op basis van deze REGEL (niet per code). Gelukkig pad + deze randgevallen: 0%, 30%, 31% (fout), negatief, totaal = 0. [code]"
Hij geeft de sterke vrijgaveregel en zegt: "schrijf de verwachting volgens de regel, niet volgens de code"; Deze enkele zin sluit de valkuil van AI die wangedrag oplost.
Testtype
AI-bijdrage
menselijke controle
Veel plezier met het testen van wegunits
snel skelet
Klopt de verwachting?
Randgevallen
Uitgebreid brainstormen
Elimineer het irrelevante
Opvullen van scope-openingen
Vindt overgeslagen takken
Bevestig de betekenis
Testgegevens/mock
Produceert een realistisch monster
Geen PII, realismecontrole
Tests beheren de kwaliteit, maar garanderen deze niet
Een hoge testdekking geeft vertrouwen, maar kan ook misleidend zijn: 100 procent dekking betekent 'elke regel is uitgevoerd', niet 'elke regel is correct'. Het is gemakkelijk om de dekking te vergroten met AI; De echte waarde ligt in het schrijven van betekenisvolle verwachtingen. De waarde van een test is het vermogen om de code te breken en u te waarschuwen wanneer de code beschadigd is. Daarom zijn door AI gegenereerde tests gebaseerd op de vraag: "Breekt de code echt als deze verandert?" Test het met de vraag; Het opzettelijk doorbreken van een lijn en het zien breken van de test (mutatie-idee) is het bewijs dat de test heeft gewerkt.
Tip: Om te zien of een test die de AI schrijft werkt, maak je een kleine bug in de code (verander bijvoorbeeld een + in een -) en kijk of de test kapot gaat. Als het niet kapot gaat, beschermt die test je niet.
Veel voorkomende fouten
- Om een test vragen zonder de regel te geven. Het model bevriest huidig gedrag; herstelt de fout als "waar".
- Verwachtingen accepteren zonder ze te lezen. Testen is misleidend als u niet controleert of de beweringen op de juiste waarde controleren.
- Gewoon het gelukkige pad testen. Echte fouten leven in de marge; Vraag expliciet naar randgevallen.
- De reikwijdte verwarren met het doel. Een hoog percentage is geen garantie voor correct gedrag.
- Echte/verborgen gegevens maken als testgegevens. Klantgegevens of -geheimen mogen niet worden getest en opgeslagen; Genereer synthetische gegevens.
Samengevat
AI neemt een groot deel van de repetitieve last weg bij het schrijven van tests: het produceert snelle skeletten, grote lijsten met randgevallen en analyses van dekkingsverschillen. Maar het meest kritische punt zijn de verwachtingen: AI heeft de neiging het huidige gedrag van de code te testen, terwijl het testen volgens de specificatie moet worden geschreven. Geef de regel, controleer de verwachtingen, dwing edge cases af en test of de tests daadwerkelijk bescherming bieden door een bug te injecteren. Testdekking is een hulpmiddel, geen doel.
Applicatie taak
Selecteer een functie en print eerst een test naar de AI door simpelweg de code ervan in te voeren; Let op de verwachtingen. Druk vervolgens de test opnieuw af, met de specificatie (vereist gedrag) voor dezelfde functie. Vergelijk de verwachtingen van de twee testsets: zijn er verschillende, welke onthult een echte bug? Controleer ten slotte of een van de gegenereerde tests werkte door een opzettelijke bug aan de code toe te voegen en de testonderbreking te zien.
controlelijst
- [ ] Ik maak onderscheid of de test bedoeld is om gedrag te corrigeren of te verifiëren.
- [ ] Wanneer ik een test aanvraag, geef ik de regel (specificatie) op die moet gelden, niet de code.
- [ ] Ik vergelijk elke gegenereerde bewering met de specificatie.
- [ ] Ik verzoek expliciet om rand- en faalgevallen.
- [ ] Ik beschouw percentagedekking als een hulpmiddel, niet als een doel.
- [ ] Ik test of een test daadwerkelijk beschermt door fouten te injecteren.