Folosiți testele ca dovezi

Începeți cu cerința

Testele oferă dovezi pentru afirmații specifice. O execuție reușită a testelor nu dovedește fiecare proprietate a software-ului. Înainte de a cere teste, identificați comportamentul important și defectul pe care fiecare verificare trebuie să îl detecteze.

Pentru un export fictiv la nivel de organizație, cerința principală este izolarea datelor. Un utilizator din organizația A nu trebuie să primească înregistrări din organizația B. Un test care verifică doar descărcarea reușită nu dovedește această cerință.

Cereți agentului să explice relația dintre cerință și aserțiune. Astfel, cazurile lipsă sunt mai ușor de detectat înainte ca suita de teste să devină mare.

Alegeți domeniul potrivit al testului

Un test unitar poate verifica rapid o transformare mică. Un test de integrare poate verifica modul în care componentele lucrează împreună. Un test end-to-end poate verifica o secvență importantă a utilizatorului în aplicația instalată în mediu sau într-o aplicație reprezentativă.

Folosiți domeniul cel mai restrâns care oferă dovezile necesare. Un instrument de formatare nu are nevoie de un test complet în browser pentru fiecare intrare. O limită de autorizare poate necesita o rută reală și calea reală de acces la date. O interacțiune critică în browser necesită dovezi despre interfața afișată.

Niciun procent fix de tipuri de teste nu se potrivește tuturor sistemelor. Alegeți în funcție de defecțiunea pe care trebuie să o detectați și de costul mentenanței verificării.

Evitați o ipoteză incorectă comună

Un agent poate scrie implementarea și testele pornind de la aceeași neînțelegere. Cele două pot concorda, în timp ce cerința rămâne neîndeplinită.

Să presupunem că implementarea filtrează înregistrările după ID-ul organizației furnizat în cerere. Testul folosește același ID pentru utilizatorul autentificat și pentru cerere. Testul trece. Cazul lipsă este un utilizator care cere ID-ul altei organizații.

Adăugați acel caz folosind identitatea de încredere și calea reală de autorizare. Un mock care returnează întotdeauna „permis” nu poate dovedi izolarea între tenant-uri. Dovedește doar comportamentul după autorizarea reușită.

Verificați dacă testul poate eșua

Pentru un defect cunoscut, executați noul test de regresie pe versiunea defectă într-un branch izolat. Confirmați că eșuează din motivul intenționat. Apoi aplicați corecția și executați-l din nou.

Un test care eșuează deoarece nu poate încărca datele de test nu oferă încă dovezi despre comportamentul de afaceri. Inspectați eșecul, nu doar codul de ieșire.

Pentru modificări mai ample, testarea prin mutații poate ajuta la evaluarea capacității unor modificări de cod selectate de a provoca eșecuri ale testelor. Are un cost și nu înlocuiește verificarea cerințelor. Folosiți-o când dovezile suplimentare susțin o decizie cu consecințe importante.

Păstrați legătura dintre dovezi și modificare

Executați verificările relevante pe versiunea finală a codului. Notați verificările omise și motivele. Un rezultat de la un commit anterior poate să nu mai fie valabil după o corecție din procesul de verificare.

Păstrați testele ușor de înțeles. Preferați o pregătire și o aserțiune explicite în locul unei funcții auxiliare mari care ascunde condiția importantă. Eliminați verificările redundante când cresc costul mentenanței fără a detecta o defecțiune diferită.

Persoana care verifică trebuie să poată spune ce dovedesc testele și ce rămâne incert. Această explicație este mai utilă decât un număr mare de teste.