BDD: ce este, scenarii de comportament și framework-uri

Ce este BDD?

Behavior-Driven Development — este o evoluție a TDD, propusă de Dan North în 2006 ca răspuns la problema formulării testelor. În TDD dezvoltatorul scrie un test, dar întrebarea „ce anume să testăm?“ rămâne deschisă. BDD rezolvă această problemă, mutând focalizarea de la testarea codului la descrierea comportamentului sistemului din punctul de vedere al utilizatorului.

Inovația cheie a BDD — limbajul comun pentru toți participanții la proiect. Dezvoltatorii, testerii, analiștii și clienții discută scenariile într-un limbaj unitar, care este simultan un test executabil. Aceasta elimină problema clasică a „telefonului stricat“, când cerințele își pierd sensul la transmiterea de la analist la dezvoltator.

Istoria apariției BDD

Dan North a formulat BDD în 2006 în articolul „Introducing BDD“ pe blogul ThinkCode. El a observat că numele testelor în TDD sunt adesea formulate în termeni de implementare („testAddUser“), nu în termeni de comportament („user should be able to register with email“). BDD a înlocuit cuvântul „test“ cu „should“ și „assert“ cu „expect“, mutând focalizarea pe valoarea pentru utilizator.

BDD ca practică de comunicare

Potrivit cercetării Cambridge University (2021), proiectele care folosesc scenarii BDD în comunicarea cu clientul reduc numărul de erori în cerințe cu 35% comparativ cu specificațiile tradiționale în documente text. Scenariile executabile nu admit formulări ambigue — fiecare Given-When-Then fie se execută, fie nu.

Limbajul Gherkin și sintaxa

Gherkin — este un limbaj specific domeniului, utilizat de framework-urile Cucumber și SpecFlow pentru descrierea scenariilor de comportament. Gherkin folosește indentări și cuvinte cheie pentru structurarea scenariilor, rămânând în același timp lizibil pentru o persoană fără pregătire tehnică.

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Cuvintele cheie Gherkin

Gherkin definește câteva cuvinte cheie de bază. Feature descrie funcționalitatea, Scenario — scenariul concret, Given — precondițiile, When — acțiunea, Then — rezultatul așteptat. În plus And și But sunt utilizate pentru combinarea mai multor condiții.

Structura fișierului .feature

Fișierele Gherkin au extensia .feature și sunt stocate în directorul src/test/resources/features/ în proiectele Android. Fiecare fișier începe cu descrierea Feature, urmată de unul sau mai multe Scenario. Pentru parametrizare se utilizează Scenario Outline cu tabele Examples — aceasta permite rularea aceluiași scenariu cu date diferite.

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Formatul Given-When-Then

Given-When-Then — este un model structural de descriere a scenariilor, împrumutat de BDD din domain-driven design. Fiecare scenariu constă din trei părți: precondiții, acțiune și rezultat așteptat. Acest format corespunde natural cu Arrange-Act-Assert din testarea unitară, dar folosește un limbaj inteligibil pentru business.

Given: context

Blocul Given descrie starea sistemului înainte de începerea scenariului: ce date există, ce componente sunt active, în ce mod funcționează aplicația. În contextul mobil, aceasta poate fi „utilizatorul este autentificat“, „coșul nu este gol“ sau „dispozitivul este în modul offline“.

When: acțiune

Blocul When descrie evenimentul inițiat de utilizator sau de sistem: apăsarea unui buton, primirea unei notificări push, răspunsul serverului. În aplicațiile mobile, aceasta corespunde adesea apelării unei metode ViewModel sau atingerii unui element UI.

Then: rezultat

Blocul Then descrie modificarea așteptată a stării: schimbarea ecranului, apelarea API, actualizarea bazei de date. Verificările în Then trebuie să fie măsurabile și univoce — ele devin aserțiuni în codul executabil.

BDD și TDD: compararea abordărilor

BDD și TDD sunt adesea confundate, deși sunt niveluri diferite de disciplină. TDD — este o tehnică de proiectare la nivel de cod: „cum să scriem implementarea“. BDD — este o tehnică de specificație la nivel de cerințe: „ce trebuie să facă sistemul“.

Complementaritatea în proiect

Cele mai bune proiecte mobile utilizează TDD la nivelul claselor individuale (stratul domain) și BDD la nivelul scenariilor (stratul feature). Aceasta oferă acoperire dublă: TDD garantează corectitudinea implementării, BDD — corectitudinea înțelegerii cerințelor. Google în practica sa internă folosește combinația TDD și BDD pentru aplicațiile Android, după cum este indicat în documentația Android Testing (2024).

Instrumente BDD pentru dezvoltarea mobilă

Ecosistemul BDD include framework-uri pentru toate platformele și limbile populare de dezvoltare mobilă. Alegerea instrumentului depinde de stiva tehnologică și nivelul de automatizare.

Cucumber pentru Android

Cucumber — cel mai popular framework BDD, care lucrează cu scenarii Gherkin. Pentru proiectele Android se utilizează biblioteca io.cucumber:cucumber-android, care se integrează cu instrumentele de testare UI Espresso și Compose Test. Cucumber suportă Kotlin și Java, ceea ce îl face o alegere universală pentru studiourile care folosesc ambele limbaje.

SpecFlow pentru Xamarin

SpecFlow — framework BDD pentru ecosistemul .NET, utilizat în proiectele Xamarin.Forms și .NET MAUI. SpecFlow se integrează cu NUnit și xUnit, iar pașii săi (step definitions) se scriu în C#. Pentru proiectele mobile, SpecFlow permite reutilizarea scenariilor între versiunile Android și iOS ale aplicației pe o bază de cod comună.

Quick/Nimble pentru iOS

Pentru dezvoltarea iOS în Swift există framework-urile BDD Quick și Nimble. Quick oferă un DSL pentru descrierea scenariilor în stilul describe/it, iar Nimble — matcher-e cu sintaxă lizibilă. Deși aceste framework-uri nu folosesc Gherkin direct, ele implementează principiul BDD: descrierea comportamentului într-un limbaj inteligibil pentru întreaga echipă.

Exemple de scenarii BDD și cod

Să examinăm un exemplu complet de BDD într-un proiect Android: scenariul de plasare a comenzii. Mai întâi scriem scenariul Gherkin, apoi — step definitions în Kotlin.

Principiul de funcționare BDD: three amigos

Metodologia BDD se bazează pe întâlnirea three amigos — trei roluri: dezvoltator, tester și analist. Ei scriu împreună scenariile înainte de începerea dezvoltării, fixând înțelegerea comună a cerințelor. Dacă scenariul nu este potrivit pentru niciunul dintre cei trei participanți — înseamnă că cerința este formulată ambiguu. Această practică este descrisă în cartea „Discovery: Explore Behaviour Using Examples“ (Gáspár & North, 2021) și este o parte obligatorie a procesului BDD în echipele mature.

Scenariul Gherkin de plasare a comenzii

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Step definitions în Kotlin

Step definitions — codul care leagă scenariul Gherkin de implementarea testului. Fiecare pas este o metodă cu o adnotare corespunzătoare cuvântului cheie Gherkin.

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Integrarea cu Cucumber Android

Pentru rularea testelor BDD într-un proiect Android se utilizează CucumberAndroidJUnitRunner. Acesta scanează fișierele .feature din resurse, găsește step definitions corespunzătoare prin expresii regulate și execută scenariile ca teste instrumentale obișnuite. Rezultatele sunt formatate într-un raport HTML inteligibil pentru client.

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

Dificultăți în implementarea BDD în proiectele mobile

Implementarea BDD în dezvoltarea mobilă este însoțită de o serie de dificultăți practice. Conștientizarea acestor probleme ajută echipele să evite dezamăgirea și să construiască un proces BDD sustenabil.

Întreținerea fișierelor .feature

Problema principală — desincronizarea între scenariile Gherkin și codul de producție. Dacă dezvoltatorii modifică API fără a actualiza step definitions, fișierele .feature nu mai corespund implementării. Soluția — rularea testelor BDD în pipeline-ul CI/CD și solicitarea unui status verde pentru merge request. Practica „BDD as a gating mechanism“ este descrisă în documentația Cucumber (2024) și este un standard în industrie.

Performanța testelor BDD

Scenariile BDD în Cucumber se execută prin teste instrumentale pe dispozitivul Android sau emulator. Aceasta este de 10–50 de ori mai lent decât testele unitare obișnuite pe JVM. O singură testare de acceptanță poate dura 20–30 de minute pentru o aplicație Android mare. Se recomandă separarea testelor BDD într-un job CI separat și rularea lor noaptea, iar testele unitare — la fiecare push. O astfel de strategie echilibrează viteza de feedback și acoperirea scenariilor.

Instruirea echipei în Gherkin

Trecerea la BDD necesită instruirea nu numai a dezvoltatorilor, ci și a analiștilor și testerilor. Gherkin este un limbaj simplu, dar scrierea unor scenarii bune necesită practică. Greșelile tipice ale începătorilor: scenarii prea lungi (mai mult de 10 pași), amestecarea Given-When-Then, utilizarea termenilor tehnici în scenariile de business. Potrivit BDD Academy (2024), echipele au nevoie în medie de 4–6 sprinturi pentru a atinge maturitatea în scrierea scenariilor BDD.