Given-When-Then: ce este, structura scenariilor și exemple

Ce este Given-When-Then?

Given-When-Then — este un șablon de descriere a comportamentului, formulat pentru prima dată de Dan North în 2006 ca parte a metodologiei Behavior-Driven Development. Șablonul rezolvă problema descrierilor nestructurate ale scenariilor de test, care conțin adesea un amestec de precondiții, acțiuni și verificări într-o ordine arbitrară.

Ideea principală a șablonului este separarea responsabilităților între cele trei blocuri. Fiecare bloc răspunde pentru exact un aspect al scenariului: starea înainte, evenimentul în timpul și verificarea după. Aceasta face scenariul lizibil, verificabil și automatizabil. Potrivit cercetării dezvoltatorilor framework-ului Cucumber (2024), scenariile care urmează strict șablonul Given-When-Then necesită cu 42% mai puțin timp pentru înțelegere de către un nou membru al echipei.

Originea șablonului

Dan North a împrumutat ideea structurii în trei părți din formulation of tests în TDD și metodologia Test-by-Example (creată de Brian Marick). Marick a propus descrierea cerințelor prin exemple (examples) care servesc simultan drept teste. Given-When-Then a formalizat această idee, transformând exemplele nestructurate într-un șablon repetabil.

Domeniul de aplicare

Șablonul Given-When-Then se aplică nu numai în scenariile BDD în Gherkin, ci și în testele unitare obișnuite în JUnit, XCTest și alte framework-uri. Comentariile în cod care împart testul în trei blocuri sunt o practică răspândită pentru îmbunătățirea lizibilității bazei de testare. Google recomandă această abordare în cartea sa „Software Engineering at Google” (2020).

Structura celor trei blocuri

Fiecare bloc Given-When-Then are o semantică strict definită și reguli de completare. Încălcarea acestor reguli duce la scenarii care sunt greu de automatizat sau de înțeles.

Given: precondiții

Blocul Given descrie starea sistemului înainte de executarea acțiunii testate. Include: obiecte existente (utilizator, comandă, setări), stări active (autentificat, conectat la rețea), precum și valori inițiale ale datelor. Fiecare Given trebuie să fie verificabil — dacă starea sistemului nu corespunde Given, scenariul trebuie omis sau mediul de test trebuie pregătit în prealabil.

When: acțiune

Blocul When descrie un singur eveniment care inițiază comportamentul testat. Acesta poate fi apelarea unei metode, apăsarea unui buton, primirea unei notificări sau a unui răspuns de la server. Regula cheie — un When per scenariu. Dacă trebuie verificată o succesiune de acțiuni — se creează scenarii separate, nu un lanț de When.

// Given: creăm date de test
val user = User(email = "test@example.com", balance = 500.0)
val product = Product(price = 150.0)

// When: executăm acțiunea
val result = PurchaseUseCase().buy(user, product)

// Then: verificăm rezultatul
assertEquals(PurchaseResult.Success, result)
assertEquals(350.0, user.balance)

Then: rezultat așteptat

Blocul Then verifică dacă sistemul a trecut în starea așteptată. Aceasta include: valori returnate, modificări ale stării obiectelor, apeluri ale serviciilor externe (prin verificare mock), precum și modificări UI. Fiecare bloc Then poate conține mai multe verificări, dar toate se referă la o singură acțiune.

Given-When-Then și Arrange-Act-Assert

Given-When-Then și Arrange-Act-Assert (AAA) — sunt două variante ale aceluiași șablon în trei părți, dar cu audiență țintă diferită. Înțelegerea diferențelor lor ajută la alegerea formatului potrivit pentru o sarcină specifică.

Când să folosești Given-When-Then

Șablonul Given-When-Then este optim pentru scenarii care sunt discutate cu clientul sau analistul: criterii de acceptare a funcționalităților, scenarii de utilizare, verificări de regresie. Sintaxa Gherkin permite scrierea unor astfel de scenarii fără cunoștințe de programare.

Când să folosești Arrange-Act-Assert

Arrange-Act-Assert — este alegerea naturală pentru testele unitare care verifică o metodă sau o clasă specifică. Formatul AAA nu necesită framework-uri suplimentare și funcționează în orice limbaj de programare. Pentru dezvoltarea iOS, Apple recomandă AAA în documentația XCTest (2024).

Exemple de scenarii în Kotlin

Să analizăm exemple practice de Given-When-Then în Kotlin pentru o aplicație Android. Primul exemplu — testarea coșului de cumpărături folosind MockK. Al doilea — testul logicii de notificări push.

Exemplul 1: coșul de cumpărături

class CartTest {
    fun `apply discount when total exceeds threshold`() {
        // Given
        val cart = Cart()
        cart.addItem(Item("Laptop", price = 1000.0))
        cart.addItem(Item("Mouse", price = 50.0))
        val discount = DiscountCalculator(0.1)

        // When
        val total = discount.applyIfEligible(cart)

        // Then
        assertEquals(945.0, total)
        assertTrue("Discount was not applied", total < 1050.0)
    }
}

Exemplul 2: notificări push cu corutine

Al doilea exemplu demonstrează Given-When-Then cu cod asincron. Aici Given stabilește starea Firebase Cloud Messaging, When — primirea notificării push, Then — verificarea procesării.

class PushNotificationTest {
    fun `handle push notification when app in background`() = runTest {
        // Given
        val prefs = mockk<SharedPreferences>()
        every { prefs.getString("token", null) } returns "fcm-token-abc"
        val handler = PushHandler(prefs)

        // When
        val data = RemoteMessage().apply {
            putData("type", "order_update")
            putData("order_id", "123")
        }
        val result = handler.handleNotification(data)

        // Then
        assertEquals(NotificationAction.OpenOrder("123"), result)
    }
}

Exemplul 3: scenariu Gherkin pentru autentificare

Al treilea exemplu — un scenariu BDD în Gherkin, care arată Given-When-Then în contextul testelor de acceptare:

Feature: User Authorization
  Scenario: User cannot login with expired token
    Given the user has an expired refresh token
    When they try to access the protected profile screen
    Then they should see the login screen
    And the app should clear all cached data

Cele mai bune practici de scriere a scenariilor

Utilizarea eficientă a Given-When-Then necesită respectarea mai multor practici dovedite. Acestea asigură lizibilitatea, mentenabilitatea și automatizabilitatea scenariilor.

Un When per scenariu

Regulă strictă: un scenariu — o acțiune. Dacă trebuie verificată o succesiune de mai multe When, creează mai multe scenarii, unde rezultatul precedentului devine precondiția următorului. Aceasta face scenariul atomic și ușor de înțeles.

Evită datele concrete în Given

Given trebuie să descrie esența, nu cifre concrete. În loc de „Given utilizatorul Ivanov cu soldul de 500 de ruble” — „Given utilizatorul cu sold suficient”. Datele concrete se mută în Scenario Outline cu tabelul Examples. Aceasta face scenariul universal și reutilizabil.

• Scrie Then ca afirmații măsurabile — „utilizatorul trebuie să vadă ecranul de autentificare”, nu „utilizatorul trebuie redirecționat”
• Folosește And pentru pași similari — dacă sunt necesare mai multe Given, combină-le prin And, nu crea un al doilea Given
• Nu amesteca nivelurile de abstracție — Given-When-Then trebuie să fie la același nivel: fie de afaceri, fie tehnic, nu în amestec
• Documentează motivul scenariului — un comentariu la începutul fișierului .feature cu descrierea regulii de afaceri ajută la context

Given-When-Then în pipeline-ul CI/CD

Integrarea scenariilor Given-When-Then în pipeline-ul de integrare continuă le transformă din documentație în protecție împotriva regresiunilor. Fiecare cerere de merge într-un proiect mobil rulează automat scenariile BDD și blochează îmbinarea dacă cel puțin un scenariu eșuează.

Rularea automată a scenariilor

Scenariile BDD în Cucumber pentru Android se rulează prin task-ul Gradle ./gradlew cucumber. Pentru iOS (Quick/Nimble) — prin xcodebuild test. În sistemele CI (GitHub Actions, GitLab CI, Bitrise) testele BDD se execută pe emulatoare sau dispozitive reale. Raportul se generează în format HTML, ușor de înțeles pentru manageri: scenarii verzi — promovate, roșii — eșec cu indicarea pasului.

Documentație vie în repository

Fișierele .feature sunt stocate în repository lângă cod și trec prin code review. Analistul creează o cerere de merge cu scenarii noi înainte de începerea dezvoltării (BDD-first). Dezvoltatorul scrie step definitions și implementarea pentru ca aceste scenarii să devină verzi. Când toate scenariile trec — funcționalitatea este gata. Această abordare, descrisă în cartea lui Gojko Adzic „Specification by Example” (2011), transformă cerințele într-un artefact executabil.