Ai auzit de BDD la un DevTalks, ai văzut un fișier .feature pe GitHub și ți‑ai zis: "Pare simplu." Și da, sintaxa Gherkin este simplă. Problema e că simplu nu înseamnă ușor de făcut bine. Există o diferență uriașă între un fișier .feature care bifează o căsuță în JIRA și unul care chiar ajută echipa să înțeleagă ce testează și de ce.
Hai să construim împreună al doilea tip.
Ce este BDD și de ce contează Gherkin?
Behavior‑Driven Development (BDD) este o abordare în care testele sunt scrise pornind de la comportamentul așteptat al aplicației, nu de la implementarea tehnică. Ideea centrală: toți cei implicați — tester, developer, product owner — să vorbească aceeași limbă atunci când descriu o funcționalitate.
Gherkin este limbajul prin care se întâmplă asta. Nu e un limbaj de programare, e un limbaj de comunicare cu structură fixă. Un fișier .feature conține unul sau mai multe scenarii, fiecare scris în forma Given‑When‑Then. Tool‑uri precum Cucumber (Java), SpecFlow (.NET) sau Behave (Python) parsează aceste fișiere și le leagă de cod executabil — step definitions.
#FunFact: Gherkin suportă peste 70 de limbi naturale, inclusiv română. Poți scrie "Dat fiind că", "Când" și "Atunci" și va funcționa. În practică, majoritatea echipelor preferă engleza pentru consistență cu restul codului, dar alegerea e a ta.
Sintaxa Given‑When‑Then: ce face fiecare parte
Fiecare scenariu Gherkin are trei blocuri logice. Le dai exemple concrete și totul devine clar:
Given — descrie starea inițială a sistemului, contextul. Nu e o acțiune, e un punct de plecare. "Given the user is logged in as an admin" sau "Given the shopping cart contains 3 items."
When — descrie acțiunea pe care utilizatorul sau sistemul o execută. Un singur When per scenariu, pe cât posibil. "When the user clicks the 'Place Order' button."
Then — descrie rezultatul așteptat, verificabil. "Then the order confirmation email is sent to the registered address" sau "Then the order status changes to 'Processing'."
Există și cuvintele‑cheie And și But, care prelungesc natural oricare dintre cele trei blocuri fără să le repete:
Given the user is on the login page
And the user has a valid account
When the user enters correct credentials
And clicks the Login button
Then the dashboard is displayed
And the session token is saved in localStorage
Observi că fiecare linie face un singur lucru. Asta nu e coincidență — e regulă.
Greșeli frecvente: unde se strică lucrurile
Am văzut zeci de fișiere .feature în cursurile noastre de la Academia Testarii și există câteva anti‑pattern‑uri care apar mereu:
Primul și cel mai des întâlnit: scenarii care testează UI în loc să testeze comportament. "When the user clicks the blue button in the top‑right corner" nu e Gherkin bun. E un script de test camuflat. Corect ar fi: "When the user submits the registration form."
Al doilea: Given prea tehnic. "Given the database contains a record with id=4472 and status='active'" sună a SQL, nu a business logic. Înlocuiește cu "Given an active customer account exists." Detaliile tehnice — MySQL, ID‑uri, token‑uri — stau în step definitions, nu în fișierul .feature.
Al treilea: un scenariu care testează prea multe lucruri deodată. Dacă ai 5 linii de When, scenariul tău e de fapt 3 scenarii lipite cu scotch. Sparge‑l.
Al patrulea: lipsa unui titlu descriptiv. "Scenario: Test login" nu ajută pe nimeni la 3 luni după ce l‑ai scris. "Scenario: Login fails when password is expired" — asta e un titlu care vorbește.
Al cincilea, specific echipelor care automatizează cu Selenium 4 sau Playwright: step definitions prea strâns cuplate de locatori CSS sau XPath. Dacă schimbi un buton în UI și cad 40 de scenarii care n‑au legătură cu acel buton, ceva e greșit în arhitectura step‑urilor, nu în Gherkin.
Scenario Outline: când ai nevoie de date multiple
Dacă testezi același flux cu valori diferite — să zicem autentificare cu 5 combinații de user/parolă — nu scrii 5 scenarii identice. Folosești Scenario Outline cu un tabel Examples:
Scenario Outline: Login with various credential combinations
Given the user is on the login page
When the user enters "<username>" and "<password>"
Then the result should be "<outcome>"
Examples:
| username | password | outcome |
| valid@user.com | correctPass1 | dashboard displayed |
| valid@user.com | wrongPass | error message shown |
| '' | correctPass1 | validation error |
Curat, lizibil, ușor de extins. Același principiu funcționează excelent în Postman când testezi un API cu seturi de date diferite — dar asta e o altă poveste.
Primul tău fișier .feature care chiar are sens
Cel mai bun prim fișier .feature nu e cel mai complex. E cel scris pentru o funcționalitate pe care toată echipa o înțelege deja, dar n‑a documentat‑o niciodată consistent.
Alege un flux critic din aplicația ta — autentificare, adăugare în coș, submit formular. Organizează un workshop de 30 de minute cu un developer și cu product owner‑ul. Scrieți scenariile împreună, pe o tablă sau în Confluence. Apoi transpune‑le în Gherkin.
Dacă după workshop toată lumea e de acord că scenariile reflectă realitatea, ai reușit. Asta e BDD: nu un tool, nu un framework, ci un proces de aliniere.
Structura unui fișier complet arată cam așa
Feature: User Authentication
As a registered customer
I want to log into my account
So that I can access my order history and saved preferences
Scenario: Successful login with valid credentials
Given the user is on the login page
When the user enters a valid email and password
And clicks the Login button
Then the user is redirected to the dashboard
And a welcome message with the user's name is displayed
Scenario: Failed login with incorrect password
Given the user is on the login page
When the user enters a valid email and an incorrect password
And clicks the Login button
Then an error message "Invalid credentials" is displayed
And the user remains on the login page
Scenario: Account locked after 5 failed attempts
Given the user has failed to log in 4 times
When the user enters incorrect credentials again
Then the account is locked
And a notification email is sent to the registered address
Simplu. Clar. Share‑uit în echipă fără nicio explicație suplimentară — ceea ce e exact scopul.
BDD nu e magie, e disciplină
La A4Q Summit și la alte evenimente din comunitatea de QA din România, BDD apare mereu în discuții ca "next step" pentru echipele care vor să treacă de la testare reactivă la una colaborativă. Și e adevărat. Dar disciplina contează mai mult decât tool‑ul.
Gherkin funcționează dacă echipa îl adoptă împreună, dacă scenariile sunt revizuite regulat și dacă step definitions‑urile sunt menținute curate. Altfel, rămâi cu un folder plin de fișiere .feature pe care nimeni nu le mai citește — și asta e mai rău decât să nu fi început.
Pasul următor ești tu. Dacă vrei să înveți BDD, Gherkin și automatizarea scenariilor de la zero sau să-ți consolidezi cunoștințele pentru certificarea ISTQB, echipa noastră de la Academia Testarii are cursuri hands‑on construite exact pentru asta. Intră pe academiatestarii.ro, uită-te la oferta de cursuri și rezervă-ți locul. Abia așteptăm să-ți vedem primul fișier .feature în acțiune. 🚀
#DeAziEstiTester #AcademiaTestarii #BDD #SoftwareTesting #TestAutomation