Câștiguri:
- Abilitatea de a produce teste unitare, cazuri marginale și analiză a decalajului de acoperire cu AI
- Abilitatea de a imprima așteptările de testare pe baza specificațiilor, nu a comportamentului curent al codului
- Abilitatea de a testa dacă un test protejează de fapt prin injectarea erorilor
Scrierea testelor este una dintre sarcinile cele mai producătoare de valoare pe care majoritatea dezvoltatorilor le amână. O suită de testare bună este dovada că codul funcționează conform așteptărilor și o linie de salvare pentru schimbările viitoare. Problema este că scrierea testelor este repetitivă și necesită timp - exact genul de muncă în care AI strălucește. Dar există o captură: AI testează adesea comportamentul existent al codului, nu comportamentul care ar trebui să fie. Gestionarea acestei diferențe este esența acestei unități.
În această unitate, veți învăța testarea unitară (testare care testează o funcție singură, în mod izolat), teste de caz marginal și generarea de date de testare cu AI; eliminarea golurilor în acoperirea testelor; și de ce este periculos să ai încredere orbește în testele AI.
Cele două părți ale testării: remedierea comportamentului vs. verificare
Un test poate servi pentru două scopuri diferite. Prima este verificarea: testează dacă codul este corect, dacă respectă specificația. A doua este protecția împotriva regresiei: îngheață comportamentul codului astăzi, așa că dacă cineva îl schimbă accidental mâine, testul se va rupe și va notifica.
AI este foarte bun la acesta din urmă; Se uită la cod și generează cazuri care testează „ce face acum”. Dar dacă codul este greșit de la început, AI poate fixa acel comportament greșit drept „corect”. Deci trebuie să revizuiți afirmația fiecărui test pe care îl produce AI: „Codul returnează 42 și testul așteaptă 42” nu înseamnă că 42 este răspunsul corect.
Atenție: Dacă AI trece testul, nu înseamnă că codul „funcționează”; înseamnă doar „se comportă așa cum se așteaptă AI”. Decizi dacă așteptarea este corectă sau nu uitându-te la specificație.
Pas cu pas: Scrierea de teste robuste cu AI
- Dați specificația, nu doar codul. Dacă adăugați informația „Această funcție ar trebui să facă acest lucru”, AI poate scrie așteptarea corectă; Acesta va testa comportamentul actual dacă doar furnizați codul.
- Solicitați huse marginale. Gol, nul, zero, negativ, prea mare, format prost, concurență - revendicați în mod explicit din calea fericită.
- Specificați cadrul și stilul de testare. „utilizați pytest”, „Aranjare-Act-Assert model”, „lasă fiecare test să testeze un lucru” etc.
- Verificați așteptările (afirmația). Comparați cu specificația pe care o verifică fiecare afirmație pentru valoarea corectă.
- Închideți golurile în domeniul de aplicare. Dați teste existente și întrebați „ce ramuri și cazuri nu au fost testate?” te fac sa intrebi; apoi verificați testele suplimentare produse.
Trei mini carcase
Cazul 1 — Acoperire de la 52% la 85%. Acoperirea de testare a unui modul de serviciu a fost de 52%. Echipa a alimentat testele existente către AI, a pus-o să listeze ramurile netestate și să genereze teste pentru ele. Odată cu revizuirea umană, acoperirea a crescut la 85%; În acest proces, AI a descoperit o eroare reală (o cale care a returnat codul de eroare greșit) într-o ramură a erorilor care nu fusese niciodată testată înainte.
Cazul 2 — Capcana de fixare a așteptărilor false. O funcție de rotunjire a banilor a fost de fapt greșită; În loc să rotunjească 2,675 la 2,67, a fost rotunjit 2,67 în loc de 2,68. AI s-a uitat la cod și a scris assert round_money(2.675) == 2.67 — înghețând eroarea ca „adevărat”. Când dezvoltatorul a citit specificația, a corectat așteptările și a prins adevărata eroare. Testarea regulii, nu a codului, a făcut diferența.
Cazul 3 – Explozie în starea marginii. Când cereți AI doar „cazuri marginale” pentru o funcție de interval de date; A produs 8 cazuri, cum ar fi început=sfârșit, interval invers, an bisect 29 februarie, fusuri orare diferite și interval nul. Două dintre acestea (spațierea inversă și anul bisect) au cauzat de fapt eroarea. Luarea în considerare a acestor cazuri manual este adesea omisă; AI a devenit aici un partener de „brainstorming de vârf”.
Patru șabloane copiabile
Generarea testelor bazate pe specificații:
Rol: Un dezvoltator care scrie teste. Framework: {{pytest/JUnit/Jest...}}. Ce TREBUIE FĂCĂ funcția (specificație): {{rule}}Scrieți teste pentru următoarea funcție. Scrieți așteptările conform specificațiilor, NU rezultatul curent al codului. Cale fericită + adăugați cel puțin 4 cazuri de margine. Lăsați fiecare test să testeze un lucru, folosiți un nume descriptiv. {{funcție}}
Brainstorming de caz marginal:
Enumerați cazurile marginale/de eșec care ar trebui încercate la testarea acestei funcție (null, null, puncte de întrerupere, format greșit, concurență, eroare externă). Pentru fiecare caz: intrare, comportament așteptat. NU scrieți încă cod, doar enumerați.{{funcție}}
Analiza decalajului de acoperire:
Mai jos sunt funcțiile și testele disponibile. Ce ramuri, condiții și cazuri nu au fost testate? Enumerați deficiențele și scrieți noi teste numai pentru deficiențe. Nu repeta cele existente. Funcție:{{funcție}}Teste:{{existing_tests}}
Date de testare / generare de obiecte simulate:
Generați date de testare realiste pentru testele {{funcție/serviciu}}: eșantioane valide, eșantioane de margine și mostre nevalide separat. Sugerați un comportament simulat simplu pentru dependența externă {{X}}. Utilizarea datelor confidențiale reale/PII; Generați date false.
Prompt slab / Prompt puternic
Slab: „Scrieți un test pentru această funcție”.
Puternic: „cu pytest. Funcția apply_discount(total, procent) — regulă: discountul trebuie să fie 0%–30%, în afara limitelor ar trebui să arunce ValueError, rezultatul ar trebui rotunjit la 2 zecimale. Scrieți așteptările după această REGULĂ (nu prin cod). Cale fericită + aceste cazuri marginale: 0%, 30%, cod total negativ. [31]% = 0.
El dă regula de eliberare puternică și spune „scrie așteptarea conform regulii, nu a codului”; Această singură propoziție închide capcana remedierii comportamentului greșit prin AI.
Tipul testului
Contribuția AI
controlul uman
Testare fericită a unității rutiere
schelet rapid
Este corectă așteptarea?
Carcase marginale
Brainstorming amplu
Eliminați irelevantul
Umplerea golului de aplicare
Găsește ramuri omise
Confirmați semnificația
Date de testare/simulare
Produce eșantion realiste
Fără PII, control realism
Testele gestionează calitatea, nu o garantează
Acoperirea ridicată a testului oferă încredere, dar poate fi și înșelătoare: o acoperire de 100% înseamnă „fiecare linie a fost rulată”, nu „fiecare linie este corectă”. Este ușor să creșteți acoperirea cu AI; Valoarea reală este în scrierea așteptărilor semnificative. Valoarea unui test este capacitatea sa de a vă sparge și de a vă alerta atunci când codul este spart. De aceea, testele generate de AI se bazează pe întrebarea „se rupe codul cu adevărat când se schimbă?” Testează-l cu întrebarea; Ruperea intenționată a unei linii și vedea întreruperea testului (ideea de mutație) este dovada că testul a funcționat.
Sfat: Pentru a vedea dacă un test pe care îl scrie AI funcționează, creați o mică eroare în cod (de exemplu, schimbați un + cu un -) și vedeți dacă testul se întrerupe. Dacă nu se rupe, acel test nu te protejează.
Greșeli comune
- Cererea unui test fără a da regula. Modelul îngheață comportamentul curent; remediază eroarea ca „adevărat”.
- Acceptarea așteptărilor fără a le citi. Testarea este înșelătoare dacă nu verificați dacă afirmațiile verifică valoarea corectă.
- Testează doar calea fericită. Erorile reale trăiesc la margine; Solicitați în mod explicit cazuri marginale.
- Confundarea domeniului de aplicare cu scopul. Un procent mare nu este o garanție a unui comportament corect.
- Realizarea de date reale/ascunse ca date de testare. Datele sau secretele clienților nu trebuie să intre în testare și stocare; Generați date sintetice.
Pe scurt
AI elimină o mare parte din sarcina repetitivă a scrierii testelor: produce schelete rapide, liste mari de cazuri marginale și analize lacunelor de acoperire. Dar punctul cel mai critic îl reprezintă așteptările: AI tinde să testeze comportamentul curent al codului, în timp ce testarea ar trebui să fie scrisă conform specificațiilor. Dați regula, verificați așteptările, aplicați cazurile marginale și testați dacă testele protejează efectiv prin injectarea unui bug. Acoperirea testului este un instrument, nu un scop.
Sarcina de aplicare
Selectați o funcție și imprimați mai întâi un test către AI, dând pur și simplu codul acestuia; Observați așteptările. Apoi imprimați din nou testul, dând specificația (comportamentul necesar) pentru aceeași funcție. Comparați așteptările celor două seturi de testare: există altele diferite, care dezvăluie o eroare reală? În cele din urmă, verificați dacă unul dintre testele generate a funcționat, adăugând o eroare intenționată la cod și văzând întreruperile testului.
lista de verificare
- [ ] Disting dacă testul este pentru a remedia sau a verifica comportamentul.
- [ ] Când solicit un test, dau regula (specificația) care ar trebui să fie în vigoare, nu codul.
- [ ] Compar fiecare afirmație generată cu specificația.
- [ ] Solicit în mod explicit cazuri de margine și eșec.
- [ ] Consider acoperirea procentuală ca un instrument, nu un obiectiv.
- [ ] Testez dacă un test protejează de fapt prin injectarea erorilor.