Gevinster:
- Evne til å produsere enhetstesting, kantsaker og analyse av dekningsgap med AI
- Evne til å skrive ut testforventninger basert på spesifikasjonen, ikke den nåværende oppførselen til koden
- Evne til å teste om en test faktisk beskytter ved å injisere feil
Å skrive tester er en av de mest verdiskapende oppgavene som de fleste utviklere utsetter. En god testpakke er et bevis på at koden fungerer som forventet og en livline for fremtidige endringer. Problemet er at det å skrive tester er repeterende og tidkrevende - akkurat den typen arbeid der AI skinner. Men det er en hake: AI tester ofte den eksisterende oppførselen til koden, ikke oppførselen den skal være. Å håndtere denne forskjellen er essensen i denne enheten.
I denne enheten vil du lære enhetstesting (testing som tester en funksjon alene, isolert), edge case-tester og generering av testdata med AI; tette hull i testdekningen; og hvorfor det er farlig å stole blindt på AI-tester.
De to sidene ved testing: Å fikse atferd vs. verifisere
En test kan tjene to forskjellige formål. Den første er verifisering: den tester at koden er riktig, at den samsvarer med spesifikasjonen. Den andre er regresjonsbeskyttelse: den fryser oppførselen til koden i dag, så hvis noen ved et uhell endrer den i morgen, vil testen bryte og varsle.
AI er veldig god på det siste; Den ser på koden og genererer saker som tester «hva den gjør akkurat nå». Men hvis koden er feil fra starten av, kan AI feste den feil oppførselen som "riktig". Så du må gjennomgå påstanden til hver test AI produserer: "Koden returnerer 42 og testen forventer 42" betyr ikke at 42 er det riktige svaret.
Forsiktig: Hvis AI-en består testen, betyr det ikke at koden "fungerer"; det betyr bare "den oppfører seg som AI forventer". Du bestemmer om forventningen er riktig eller ikke ved å se på spesifikasjonen.
Trinn for trinn: Skrive robuste tester med AI
- Oppgi spesifikasjonen, ikke bare koden. Hvis du legger til informasjonen "Denne funksjonen skal gjøre dette", kan AI skrive riktig forventning; Den vil teste gjeldende oppførsel hvis du bare oppgir koden.
- Be om kantsaker. Tom, null, null, negativ, for stor, dårlig format, samtidighet – hev deg eksplisitt utenfor den lykkelige veien.
- Spesifiser testramme og stil. "bruk pytest", "Arrange-Act-Assert-mønster", "la hver test teste én ting" osv.
- Sjekk forventninger (påstand). Sammenlign med spesifikasjonen som hver påstand sjekker for riktig verdi.
- Lukk hull i omfang. Gi eksisterende tester og spør "hvilke grener og saker har ikke blitt testet?" få deg til å spørre; deretter bekrefte ytterligere tester produsert.
Tre minivesker
Tilfelle 1 — Dekning fra 52 % til 85 %. Testdekningen av én servicemodul var 52 %. Teamet matet de eksisterende testene til AI, fikk den til å liste opp de ikke-testede grenene og generere tester for dem. Med menneskelig vurdering økte dekningen til 85 %; I prosessen avdekket AI en faktisk feil (en bane som returnerte feil feilkode) i en feilgren som aldri hadde blitt testet før.
Tilfelle 2 - Den falske forventningsfikseringsfellen. En pengeavrundingsfunksjon var faktisk feil; I stedet for å runde 2,675 til 2,67, ble det rundet 2,67 i stedet for 2,68. AI så på koden og skrev assert round_money(2.675) == 2.67 — fryser feilen som "sann". Da utvikleren leste spesifikasjonen, korrigerte han forventningen og fanget opp den virkelige feilen. Testing av regelen, ikke koden, gjorde forskjellen.
Tilfelle 3 — Kanttilstandseksplosjon. Når du ber AI om bare "edge cases" for en datoperiodefunksjon; Den produserte 8 tilfeller som start=slutt, reversert intervall, skuddår 29. februar, forskjellige tidssoner og nullintervall. To av disse (omvendt avstand og skuddår) var faktisk årsaken til feilen. Å vurdere disse tilfellene manuelt blir ofte hoppet over; AI ble en "edge-case brainstorming"-partner her.
Fire kopierbare maler
Spesifikasjonsbasert testgenerering:
Rolle: En utvikler som skriver tester. Rammeverk: {{pytest/JUnit/Jest...}}.Hva SKAL funksjonen GJØRE (spesifikasjon): {{regel}}Skriv tester for følgende funksjon. Skriv forventninger i henhold til spesifikasjonen, IKKE gjeldende utgang av koden. Glad sti + legg til minst 4 kantsaker. La hver test teste én ting, bruk beskrivende navn. {{funksjon}}
Edge case brainstorming:
List kant/feil tilfeller som bør prøves i testing for denne funksjonen (null, null, bruddpunkter, dårlig format, samtidighet, ekstern feil). For hvert tilfelle: input, forventet oppførsel. IKKE skriv kode ennå, bare skriv opp.{{function}}
Analyse av dekningsgap:
Nedenfor er funksjonene og tilgjengelige tester. Hvilke grener, forhold og tilfeller er ikke testet? List opp manglene og skriv nye tester kun for manglene. Ikke gjenta eksisterende. Funksjon:{{function}}Tester:{{existing_tests}}
Testdata / mock-objektgenerering:
Generer realistiske testdata for {{function/service}}-tester: gyldige prøver, kantprøver og ugyldige prøver separat. Foreslå en enkel falsk oppførsel for den eksterne avhengigheten {{X}}. Bruk av ekte konfidensiell data/PII; Generer falske data.
Svak forespørsel / Sterk forespørsel
Svak: "Skriv en test for denne funksjonen."
Sterk: "med pytest. Funksjon apply_discount(total, percent) — regel: rabatt må være 0%–30%, out of bounds skal gi ValueError, resultatet skal avrundes til 2 desimaler. Skriv forventninger etter denne REGEL (ikke etter kode). Happy path + disse kanttilfellene: 0%, 30%, [31%, error.), negativt"=0.
Han gir den sterke frigjøringsregelen og sier "skriv forventningen i henhold til regelen, ikke koden"; Denne enkeltsetningen lukker fellen med AI som fikser feil oppførsel.
Testtype
AI-bidrag
menneskelig kontroll
Lykke til med testing av vegenhet
raskt skjelett
Er forventningen riktig?
Kantsaker
Omfattende brainstorming
Fjern det irrelevante
Omfang gap fylling
Finner hoppede grener
Bekreft betydning
Test data/mock
Gir realistisk prøve
Ingen PII, realismekontroll
Tester styrer kvalitet, ikke garanterer det
Høy testdekning gir selvtillit, men det kan også være misvisende: 100 prosent dekning betyr «hver linje ble kjørt», ikke «hver linje er korrekt». Det er enkelt å øke dekningen med AI; Den virkelige verdien er å skrive meningsfulle forventninger. Verdien av en test er dens evne til å bryte og varsle deg når koden er ødelagt. Det er derfor AI-genererte tester er basert på spørsmålet "bryter koden virkelig når den endres?" Test det med spørsmålet; Å bevisst bryte en linje og se testbruddet (mutasjonsidé) er et bevis på at testen fungerte.
Tips: For å se om en test AI skriver fungerer, lag en liten feil i koden (for eksempel endre en + til en -) og se om testen går i stykker. Hvis den ikke går i stykker, beskytter den testen deg ikke.
Vanlige feil
- Be om en test uten å oppgi regelen. Modellen fryser gjeldende atferd; fikser feilen som "true".
- Godta forventninger uten å lese dem. Testing er misvisende hvis du ikke sjekker at påstandene sjekker for riktig verdi.
- Bare tester den lykkelige veien. Virkelige feil lever på marginene; Be om kantsaker eksplisitt.
- Ta feil av omfanget for formålet. En høy prosentandel er ingen garanti for korrekt oppførsel.
- Lage ekte/skjult data som testdata. Kundedata eller hemmeligheter skal ikke inn i testing og lagring; Generer syntetiske data.
Oppsummert
AI tar mye av den repeterende byrden ved å skrive tester: den produserer raske skjeletter, store lister over kantsaker og analyser av dekningsgap. Men det mest kritiske punktet er forventninger: AI har en tendens til å teste den nåværende oppførselen til koden, mens testing bør skrives i henhold til spesifikasjonen. Gi regelen, sjekk forventningene, håndhev kantsaker, og test om testene faktisk beskytter ved å injisere en feil. Testdekning er et verktøy, ikke et mål.
Søknadsoppgave
Velg en funksjon og skriv først ut en test til AI-en ved ganske enkelt å oppgi koden; Legg merke til forventningene. Skriv deretter ut testen på nytt, og oppgi spesifikasjonen (påkrevd oppførsel) for samme funksjon. Sammenlign forventningene til de to testsettene: er det noen forskjellige, hvilken avslører en ekte feil? Til slutt, kontroller at en av de genererte testene fungerte ved å legge til en tilsiktet feil i koden og se testbruddet.
sjekkliste
- [ ] Jeg skiller om testen er for å fikse eller bekrefte atferd.
- [ ] Når jeg ber om en test, gir jeg regelen (spesifikasjonen) som skal være på plass, ikke koden.
- [ ] Jeg sammenligner hver genererte påstand med spesifikasjonen.
- [ ] Jeg ber eksplisitt om kant- og sviktsaker.
- [ ] Jeg ser på prosentvis dekning som et verktøy, ikke et mål.
- [ ] Jeg tester om en test faktisk beskytter ved å injisere feil.