Ai găsit un bug. Bine. Dar acum vine întrebarea care blochează orice junior cel puțin o dată: "Îl testez la nivel de unit, integration sau end‑to‑end?" Dacă ai stat vreodată cu cursorul suspendat deasupra unui fișier de test, nesigur de unde să începi, postul acesta e pentru tine.
Nu e vorba de teoria din manuale. E vorba de un mindset practic pe care îl poți aplica mâine dimineață, indiferent dacă lucrezi pe o aplicație bancară, un portal de retail sau un sistem din automotive.
TL;DR: Tipul defectului îți spune nivelul de testare. Dacă defectul stă într‑o singură funcție — unit test. Dacă implică două componente care vorbesc între ele — integration test. Dacă afectează un flux complet din perspectiva utilizatorului — end‑to‑end. Citește mai departe să înțelegi cum le deosebești în practică.
Ce înseamnă, de fapt, fiecare nivel de testare
Să le punem pe masă fără jargon inutil.
Un unit test izolează cea mai mică bucată de logică din cod — o funcție, o metodă, un modul — și o testează independent, fără baze de date, fără rețea, fără interfață. Rapid, precis, rulează în secunde.
Un integration test verifică că două sau mai multe componente funcționează corect împreună: de exemplu, că un serviciu de autentificare scrie corect în MySQL sau că un API returnează răspunsul așteptat când primește un request real. Aici intră în scenă și dependențele externe.
Un test end‑to‑end (E2E) simulează comportamentul unui utilizator real printr‑un flux complet: login, completare formular, trimitere, confirmare. Selenium 4, Playwright sau Cypress sunt tool‑urile cu care veți face cunoștință cel mai des la acest nivel.
Toate trei sunt necesare. Niciuna nu o înlocuiește pe cealaltă. Întrebarea nu e "care e mai bună?" — întrebarea e "care e potrivită pentru defectul pe care îl am acum?"
Cum recunoști tipul defectului: 3 întrebări rapide
Când găsești un bug, pune-ți aceste trei întrebări în ordine
1. Defectul apare indiferent de contextul din jur, chiar și când apelez funcția în izolare? → Unit test.
2. Defectul apare doar când două componente interacționează (ex: serviciul A trimite date la serviciul B și ceva se pierde pe drum)? → Integration test.
3. Defectul apare doar când urmez un flux complet, de la primul click până la rezultatul final vizibil în UI? → End‑to‑end test.
Dacă răspunzi "da" la prima întrebare, nu are rost să pornești Cypress și să aștepți 3 minute pentru un test E2E. Rezolvi problema la sursă, cu un unit test care rulează în 200 de milisecunde.
Acesta e unul dintre cele mai frecvente antipattern‑uri pe care le vedem în echipele de juniori: se sare direct la E2E pentru orice, pentru că "e mai ușor de înțeles vizual". Rezultatul? O suită de teste lentă, fragilă, greu de menținut.
Exemple reale ca să fixezi conceptul
Să zicem că lucrezi pe o aplicație de ospitalitate — rezervări de camere. Găsești un bug: prețul calculat pentru 3 nopți e greșit.
Dacă logica de calcul stă într‑o funcție de tip `calculateTotalPrice(nights, ratePerNight)`, defectul e la nivel de unit. Scrii un unit test cu câteva valori de intrare și ieșire așteptată. Gata.
Dacă prețul vine corect din funcție, dar e salvat greșit în baza de date MySQL din cauza unei conversii de tip, defectul e la nivel de integration. Ai nevoie de un test care să verifice întregul flux de scriere și citire din baza de date.
Dacă prețul e corect în bază, dar se afișează greșit în UI după un flux de rezervare complet, atunci da — pornești Playwright sau Selenium 4 și reproduci pașii utilizatorului.
Același bug, trei investigații diferite. Fiecare la nivelul potrivit.
Piramida de testare: aliatul tău tăcut
Sigur ai auzit de test pyramid. Nu e doar un desen frumos din prezentări de la DevTalks sau A4Q Summit — e o regulă practică de distribuție a efortului.
Regula de bază: mai multe unit tests, mai puține integration tests, și chiar mai puține E2E tests. De ce? Pentru că fiecare nivel superior e mai lent, mai fragil și mai scump de menținut.
Un pipeline CI/CD sănătos rulează sute de unit tests în câteva zeci de secunde, zeci de integration tests în câteva minute și un set selectiv de E2E tests pe fluxurile critice. Dacă ai invers — puține unit tests și o sumedenie de E2E — ești în zona pe care practicienii o numesc "ice cream cone anti‑pattern". Nu e locul unde vrei să fii.
Când deschizi JIRA și vezi un bug raportat, gândește‑te la piramidă: la ce nivel se află cel mai probabil defectul? Acolo începi investigația, acolo scrii primul test de regresie.
Greșeala pe care o fac aproape toți juniorii (și cum o eviți)
Cea mai frecventă greșeală nu e că alegi nivelul greșit. E că nu alegi deloc — și reproduci manual bug‑ul de zece ori fără să scrii niciun test automat, sperând că "o să-l verifici data viitoare".
Data viitoare poate fi prea târziu. Un defect care se întoarce în producție după ce a fost "rezolvat" e un defect de două ori mai costisitor — și de două ori mai stânjenitor în standup.
Mindset‑ul corect e: orice bug confirmat merită cel puțin un test de regresie la nivelul cel mai de jos la care poate fi reprodus. Dacă îl poți reproduce cu un unit test, nu ai nevoie de E2E. Dacă nu îl poți prinde la nivel de unit, urci o treaptă.
Simplu. Imediat aplicabil. Testat în producție — la propriu.
De unde continui de aici
Teoria e clară. Dar diferența dintre un junior care știe despre unit tests și unul care știe să le și scrie în contextul unui proiect real e enormă pe piața muncii din România.
La Academia Testarii îți oferim exact contextul acela real: cursuri hands‑on unde înveți să navighezi între niveluri de testare, să citești o arhitectură, să decizi unde să plasezi un test case și să-ți construiești un portfolio pe care îl poți arăta la primul interviu. Nu teorie uscată — exerciții pe scenarii din domenii cu care te vei întâlni: bancar, retail, energie, automotive.
Dacă ești la începutul drumului sau vrei să-ți structurezi mai bine cunoștințele deja acumulate, intră pe academiatestarii.ro și uită-te la programele noastre. Dacă îți dorești și o recunoaștere formală a competențelor, certificările ISTQB pe care le pregătim acoperă exact această gândire sistematică — de la niveluri de testare până la tehnici de design al testelor.
Primul pas e întotdeauna cel mai greu. Dar acum știi deja unde să te uiți primul. 😊
#DeAziEstiTester #AcademiaTestarii #SoftwareTesting #TestAutomation #ISTQB