Ce este un test și la ce folosește

Claude Code a modificat codul și a scris: "Testele au trecut". În spatele acestei fraze scurte se află fișiere cu verificări, o comandă de rulare și rezultate concrete. Mai întâi, să vedem ce feluri de testare există și ce puteți verifica manual, apoi vom analiza un test automat și ce ne spune rezultatul lui.

Ne ajunge un exemplu simplu cu acordarea punctelor. Nu trebuie să cunoașteți dinainte bibliotecile de testare: vom parcurge mai întâi scenariul manual, apoi vom formula așteptările pentru testele automate și vom citi raportul de execuție.

Ce feluri de testare există

Testarea vă ajută să aflați cum se comportă un program, dacă respectă cerințele și unde apar problemele. De exemplu, dacă punctele sunt acordate corect, dacă se poate trimite o cerere cu un câmp gol sau dacă mesajul de eroare este clar. Pentru asta, se stabilesc condițiile verificării, se parcurg pașii și se analizează rezultatul.

Testarea poate fi împărțită după mai multe criterii. Să începem cu întrebarea cine execută pașii și verifică rezultatul:

• testarea manuală - o persoană parcurge singură verificarea și evaluează rezultatul;
• testarea automatizată - o parte dintre verificări sunt încredințate unui program: acesta execută pașii și comparațiile stabilite. De obicei, astfel de verificări se numesc teste automate.

Această împărțire ține de modul de execuție. Mai există o întrebare: ce anume se verifică. Verificările funcționale țin de comportament: de exemplu, dacă au fost acordate punctele cuvenite. Cele nefuncționale țin de caracteristici ale aplicației: de pildă, cât de repede răspunde sau cât de ușor este de folosit. Criteriile sunt independente: aceeași funcție poate fi verificată atât manual, cât și automat.

Automatizarea nu elimină implicarea oamenilor. Tot trebuie să alegeți scenariile utile, să stabiliți așteptările și să înțelegeți diferențele găsite. Programul preia doar partea repetitivă a muncii.

Ce este testarea manuală

La testarea manuală, dumneavoastră parcurgeți pașii și vedeți dacă rezultatul corespunde așteptărilor. Nu e obligatoriu să scrieți codul unui test. Aveți nevoie de condiții clare și de o întrebare la care vreți să răspundeți.

Să presupunem că, în portalul didactic, fiecare potrivire valorează 10 puncte, deci trei potriviri înseamnă 30. Puteți verifica manual acordarea punctelor astfel:

1. deschideți versiunea potrivită a portalului și pregătiți un utilizator cu soldul zero, care nu a primit încă recompensa;
2. pregătiți o cerere cu trei potriviri și trimiteți-o o singură dată;
3. verificați soldul după trimitere: ar trebui să fie 30 de puncte;
4. notați rezultatul obținut. Dacă numărul e diferit, păstrați pașii și, la nevoie, captura de ecran.

Soldul inițial contează. Dacă soldul avea deja 20 de puncte, după acordare vă așteptați la 50, nu la 30. Fără condițiile inițiale, e ușor să luați un rezultat corect drept eroare sau invers.

E util să notați pe scurt rezultatul verificării: "Sold înainte de trimitere 0, trei potriviri, o trimitere, se așteptau 30, s-au obținut 3". Din această notă, o altă persoană sau Claude Code va înțelege ce trebuie reprodus. "Punctele se comportă ciudat" nu explică nimic.

Testarea manuală poate fi și exploratorie: explorați aplicația și inventați verificări pe măsură ce înaintați. De exemplu, observați că butonul rămâne activ după trimitere și decideți să verificați ce se întâmplă la o a doua apăsare. Nu există un traseu stabilit dinainte pentru fiecare pas, dar scopul rămâne clar: să înțelegeți comportamentul și să notați problemele găsite. Nu doar să apăsați la întâmplare.

Puteți folosi fără probleme și instrumente. Puteți deschide consola browserului, verifica răspunsul serverului, face o captură de ecran sau ține o listă de verificări. "Manuală" înseamnă că o persoană conduce verificarea și evaluează rezultatul, nu că lucrează fără instrumente.

Verificarea manuală e utilă când explorați un comportament nou sau evaluați cât de clară este interfața. Cea automată e utilă când pașii și comparațiile deja descrise trebuie repetate de multe ori. Nu e o împărțire strictă de tipul "interfața doar manual, calculele doar în cod": puteți automatiza și pașii din browser, iar un calcul îl puteți verifica manual.

Când apăsați butonul de pornire a testelor automate, asta nu înseamnă că testarea e manuală: după pornire, programul execută verificările. Dacă Claude Code vă face o listă de pași, iar dumneavoastră parcurgeți portalul și evaluați rezultatul, verificarea rămâne manuală. Agentul doar v-a ajutat s-o pregătiți.

Ce este un test automat

Imaginați-vă că verificați un calculator. Introduceți 2 + 2, vă așteptați dinainte la 4 și comparați numărul de pe ecran cu așteptarea. Dacă vedeți 5, știți că rezultatul este greșit pentru acest exemplu. Cunoașteți răspunsul corect indiferent de ce afișează calculatorul.

Un test automat face ceva asemănător, doar că în cod. Este un program mic care stabilește condițiile inițiale, execută o acțiune și verifică rezultatul. În locul unei persoane, codul face comparația. De aici înainte îi vom spune simplu test.

Să revenim la portalul cu recompense: o potrivire aduce 10 puncte, iar pentru trei se acordă 30. Putem descrie verificarea astfel:

1. pregătim numărul de potriviri: 3;
2. calculăm recompensa;
3. verificăm dacă valoarea recompensei este 30.

Acesta va deveni un test. Are un exemplu cunoscut dinainte și un răspuns așteptat. Regula "10 puncte pentru fiecare potrivire" se aplică portalului nostru didactic; într-o altă aplicație poate fi diferită.

Testul nu inventează singur câte puncte trebuie să primească utilizatorul. Cineva trebuie să preia regula din cerințe și să noteze așteptarea. Poate face asta un dezvoltator sau Claude Code, la cererea dumneavoastră, dar trebuie totuși să verificați dacă așteptarea corespunde sarcinii.

De ce repetăm verificarea

O singură verificare manuală a punctajului e simplă. Problema apare mai târziu: adăugați un tip nou de recompensă, schimbați procesarea cererii sau îi cereți agentului să simplifice o funcție. După fiecare modificare revine aceeași întrebare: trei potriviri mai dau tot 30?

Puteți pregăti cererea, parcurge pașii și verifica rezultatul de fiecare dată. Sau puteți scrie verificarea în cod, ca s-o rulați din nou. În aceleași condiții inițiale, testul va repeta pașii și comparația. Fără să explicați iar unde să apăsați și ce rezultat e corect.

Pe măsură ce proiectul crește, se adună și regulile. O cerere fără potriviri nu trebuie să adauge puncte; aceeași cerere nu poate fi luată în calcul de două ori; lista recompenselor trebuie să aibă o anumită ordine. Puteți rula verificările împreună și vedea care așteptare nu mai este respectată după o modificare.

Acesta e avantajul automatizării: verificarea repetată a comportamentului descris cere mai puțină muncă manuală. Scrierea testelor ia și ea timp, iar când se schimbă cerințele trebuie revizuite. Dar pentru regulile la care reveniți des, efortul se amortizează prin rulări repetate.

Unde se află testele

Testele sunt păstrate în fișiere obișnuite ale proiectului. Într-un proiect JavaScript mic, e convenabil să puneți verificarea lângă codul pe care îl apelează:

reward-example/
├── package.json
└── src/
    ├── reward-flow.js
    └── reward-flow.test.js

În reward-flow.js se află calculul recompensei. reward-flow.test.js conține codul care apelează calculul și îi verifică răspunsul. Fișierul package.json descrie setările și comenzile proiectului, inclusiv comanda de testare.

Partea .test.js din nume vă ajută să recunoașteți fișierul de verificare. Este o convenție acceptată de instrumentele de testare, nu o regulă separată a limbajului JavaScript. În alte proiecte se folosesc alte denumiri sau un folder separat tests/. Un fișier poate conține mai multe teste; nu e obligatoriu să existe câte un fișier de test lângă fiecare fișier sursă.

Dacă Claude Code lucrează într-un proiect necunoscut, cereți-i mai întâi să găsească testul existent pentru acordarea punctelor și să vă arate calea lui. Astfel puteți lega verificarea de comportamentul dorit chiar dacă nu cunoașteți încă toate folderele.

Cum transformăm intenția într-o verificare

Cererea "repară punctajul și verifică-l cu teste" îi lasă agentului deodată două întrebări: ce înseamnă un punctaj corect și prin ce se confirmă rezultatul. Mai bine porniți de la comportamentul dorit. De exemplu: "Fiecare potrivire valorează 10 puncte. Pentru trei potriviri, recompensa trebuie să fie 30".

Puteți transforma această intenție într-o verificare fără să scrieți niciun rând de cod. Descrieți trei lucruri:

Toate acestea se pot rezuma într-o singură frază: "Dacă avem trei potriviri, recompensa calculată trebuie să fie de 30 de puncte". E suficient pentru a discuta ce verifică testul. Agentul poate decide cum să scrie verificarea în codul acestui proiect.

E important să alegeți ce anume vreți să confirmați. "Recompensa calculată este 30" și "soldul utilizatorului a ajuns la 30" sunt așteptări diferite. Pentru a doua, aveți nevoie de soldul inițial și de acțiunea de acordare, ca în verificarea manuală de mai sus. De aceea, în loc de "verifică punctele", descrieți exact ce trebuie observat.

Apoi gândiți-vă la situațiile apropiate. Pentru regula noastră, e suficient să începem cu un tabel mic:

Nu trebuie să inventați zeci de cazuri din prima. Începeți cu scenariul problematic și cu câteva situații apropiate pe care modificarea le-ar putea afecta. Dacă nu e clar ce ar trebui să se întâmple, de exemplu la o cerere repetată, clarificați mai întâi regula. Agentul poate propune o variantă, dar asta nu înseamnă că așteptarea a fost convenită.

Cum îi cereți lui Claude Code să facă verificarea

După ce ați formulat comportamentul așteptat, puteți organiza munca în jurul lui. Mai întâi, agentul află ce verificări există deja în proiect, apoi le compară cu scenariile dumneavoastră. E posibil ca verificarea necesară să existe deja; atunci trebuie s-o rulați și să-i citiți rezultatul. Dacă lipsește, agentul va trebui să adauge un test.

Prima cerere ar putea suna astfel:

Trebuie reparat calculul recompensei.
Regulă: fiecare potrivire valorează 10 puncte.
Cazuri de verificat: 3 potriviri dau 30 de puncte,
0 dau 0, iar 5 dau 50.

Înainte de modificări, găsește verificările existente pentru aceste cazuri.
Descrie pe scurt ce se verifică deja, ce lipsește
și ce teste propui să adaugi sau să modifici.
Dacă există neclarități în cerințe, semnalează-le.
Deocamdată, nu modifica fișierele.

Citiți răspunsul ca pe o descriere a rezultatului viitor. Numerele din toate cazurile respectă regula dumneavoastră? Se verifică valoarea recompensei sau altceva? Propune agentul să schimbe regula doar ca să se potrivească comportamentului actual? În această etapă clarificați sarcina, fără să fie nevoie să citiți implementarea testului.

După ce ați clarificat scenariile, cereți-i să treacă la lucru:

Repară calculul conform regulii discutate.
Adaugă verificările lipsă pentru cazurile convenite,
folosind instrumentele deja adoptate în proiect.
Nu modifica așteptările existente doar ca să treacă rularea.
Dacă ți se pare greșită o așteptare, explică mai întâi de ce.

Rulează testele necesare conform instrucțiunilor proiectului.
Arată comanda, folderul de lucru și rezultatul efectiv.
Pentru fiecare dintre cele trei cazuri, spune ce test l-a verificat
și cum s-a încheiat. Enumeră separat testele omise
și verificările nerulate.

Agentul găsește comanda de rulare în documentația și setările proiectului. Într-un proiect JavaScript, aceasta este adesea npm test: npm execută comanda din câmpul scripts.test al fișierului package.json. În spatele acestui nume poate fi un set diferit de verificări. Dumneavoastră trebuie să vă asigurați că rularea include scenariile necesare.

Scrierea unui test și rularea lui sunt etape diferite. Mesajul "am adăugat trei verificări" confirmă doar că s-au modificat fișiere. Pentru a evalua rezultatul, testele trebuie rulate efectiv. Dacă nu se pot rula, de exemplu din cauza unei dependențe lipsă, agentul trebuie să spună ce l-a împiedicat și ce verificări au rămas neexecutate.

În răspuns, urmăriți legătura "scenariul nostru → testul concret → rezultat". Dacă dintre cele trei cazuri discutate s-a executat doar unul, doar acela e confirmat deocamdată. Chiar dacă linia finală e verde.

Cum citiți rezultatul

Mai jos este o rulare reală a unui test didactic, pe Node.js 20.18.0 și npm 10.8.2. Verifică doar calculul recompensei pentru trei potriviri, nu întregul set de scenarii propus mai sus. Pentru lizibilitate, am eliminat liniile cu timpul și elementele auxiliare ale raportului:

> reward-example@1.0.0 test
> node --test --test-reporter=tap

# Subtest: three matches give 30 points
ok 1 - three matches give 30 points

# tests 1
# suites 0
# pass 1
# fail 0
# cancelled 0
# skipped 0
# todo 0

Primele două linii arată pachetul și comanda executată. Mai jos este numele testului. Linia ok 1 înseamnă că testul numărul 1 a trecut; la un test eșuat, linia începe cu not ok. Liniile pass 1 și fail 0 arată că un test a trecut și niciunul nu a eșuat. Asta se numește rezultat "verde", chiar dacă terminalul nu colorează textul.

În varianta cu eroare, pentru trei potriviri se obțin 3 puncte, deși regula prevede 30. Același test afișează fragmentul de mai jos; calea, stiva de apeluri, timpul și o parte din liniile auxiliare au fost omise:

not ok 1 - three matches give 30 points
  error: |-
    Expected values to be strictly equal:

    3 !== 30

  code: 'ERR_ASSERTION'
  name: 'AssertionError'
  expected: 30
  actual: 3
  operator: 'strictEqual'

# tests 1
# pass 0
# fail 1
# cancelled 0
# skipped 0
# todo 0

Mai întâi găsiți numele testului, apoi comparați expected și actual. Primul înseamnă "așteptat", al doilea - "obținut". Aici se așteptau 30, dar s-au obținut 3. Linia fail 1 rezumă situația: un test a eșuat.

Un astfel de eșec arată că rezultatul obținut nu corespunde așteptării notate. Următorul pas este să aflați cauza: o eroare de calcul, date inițiale greșite sau o așteptare incorectă chiar în test. Nu schimbați valoarea verificată doar ca raportul să arate bine; verificați mai întâi regula sarcinii.

Se poate întâmpla și alt tip de eșec: de exemplu, testul nu a putut încărca fișierul cu funcția. Atunci nici nu a ajuns la compararea punctelor, iar raportul poate să nu arate numele testului necesar, ci să marcheze întregul fișier ca eșuat. De aceea, doar linia fail 1 nu e suficientă pentru concluzia "calculul e greșit". Citiți mesajul de deasupra rezumatului.

Test omis

Un test mai poate avea o stare importantă. Verificarea poate fi marcată ca omisă; în Node.js, de exemplu, se poate folosi test.skip. Testul nu se execută. Faptul că numele lui apare în raport nu înseamnă că scenariul a fost verificat.

Într-o rulare separată a exemplului nostru, testul omis a produs linia și rezultatele de mai jos:

ok 1 - three matches give 30 points # SKIP

# tests 1
# pass 0
# fail 0
# cancelled 0
# skipped 1
# todo 0

Observați un detaliu mai puțin obișnuit: linia începe cu ok, dar se termină cu # SKIP. Așa marchează formatul acesta un test omis. Nu vă orientați doar după primul cuvânt; rezultatul pass 0 confirmă că niciun test nu a trecut.

Să comparăm cele trei rulări ale aceluiași scenariu:

Rapoartele mai mari conțin și alte linii. În rulările noastre, cancelled și todo sunt zero. Dacă vedeți valori nenule, aflați ce teste au fost anulate sau marcate ca neterminate; nu le treceți printre verificările reușite. Linia suites ține de grupurile de teste; în exemplul nostru nu există grupuri.

Încă un detaliu. Dacă raportul arată zero teste, lipsa eșecurilor nu confirmă acordarea punctelor. Verificarea necesară poate să nu fi fost inclusă în rulare. Numele scenariului și numărul de verificări executate contează mai mult decât impresia generală dată de culoarea terminalului.

Ce înseamnă un rezultat verde

Testul din raportul de mai sus a răspuns la o întrebare precisă: "Este calculată corect recompensa pentru trei potriviri?" Nu a verificat zero potriviri, o cerere repetată sau numărul afișat pe pagină. Aceste cazuri nu devin verificate doar pentru că le-am menționat în cerere.

Pentru a verifica zero potriviri, aveți nevoie de un alt scenariu, cu așteptarea separată de 0. Pentru a verifica o cerere repetată, descrieți exact acțiunea repetată și rezultatul așteptat. Testul nu va ghici aceste reguli din codul din jur. Se verifică doar ce este scris în test.

Lipsa unui test nu e același lucru cu omiterea lui. Un test omis apare în raport ca skipped. În schimb, raportul nu spune de obicei nimic despre un scenariu pentru care nu s-a scris deloc o verificare. Toate testele existente pot trece, deși un comportament neverificat conține o eroare.

În plus, o comparație reușită nu face automat corectă așteptarea. Dacă, pentru regula noastră, notăm greșit 3 în loc de 30, iar calculul dă 3, comparația va trece. De aceea, când discutați verificarea, e util să răspundeți la două întrebări: ce comportament verifică testul și de unde vine rezultatul așteptat?

Expresia "testele au trecut" e utilă când îi înțelegeți limitele. Ea spune că anumite verificări au fost executate cu succes într-o anumită rulare. Nu promite că "aplicația nu mai are nicio eroare".