Given-When-Then: co to je, struktura scénářů a příklady

Co je Given-When-Then?

Given-When-Then — je vzor pro popis chování, který poprvé formuloval Dan North v roce 2006 jako součást metodologie Behavior-Driven Development. Vzor řeší problém nestrukturovaných popisů testovacích scénářů, které často obsahují směs předpokladů, akcí a kontrol v libovolném pořadí.

Hlavní myšlenkou vzoru je oddělení odpovědností mezi třemi bloky. Každý blok odpovídá za přesně jeden aspekt scénáře: stav před, událost během a kontrolu po. To činí scénář čitelným, ověřitelným a automatizovatelným. Podle výzkumu vývojářů frameworku Cucumber (2024) vyžadují scénáře, které striktně dodržují vzor Given-When-Then, o 42 % méně času na pochopení novým členem týmu.

Původ vzoru

Dan North si vypůjčil myšlenku třídílné struktury z formulation of tests v TDD a metodologie Test-by-Example (vytvořené Brianem Marickem). Marick navrhl popisovat požadavky prostřednictvím příkladů (examples), které zároveň slouží jako testy. Given-When-Then tuto myšlenku formalizoval a přeměnil nestrukturované příklady na opakovatelný vzor.

Oblast použití

Vzor Given-When-Then se aplikuje nejen v BDD scénářích v Gherkinu, ale také v běžných unit testech v JUnit, XCTest a dalších frameworkách. Komentáře v kódu rozdělující test do tří bloků jsou běžnou praxí pro zlepšení čitelnosti testovací základny. Google doporučuje tento přístup ve své knize „Software Engineering at Google” (2020).

Struktura tří bloků

Každý blok Given-When-Then má striktně definovanou sémantiku a pravidla plnění. Porušení těchto pravidel vede ke scénářům, které jsou obtížně automatizovatelné nebo srozumitelné.

Given: předpoklady

Blok Given popisuje stav systému před provedením testované akce. Zahrnuje: existující objekty (uživatel, objednávka, nastavení), aktivní stavy (autorizován, připojen k síti) a počáteční hodnoty dat. Každý Given musí být ověřitelný — pokud stav systému neodpovídá Given, scénář by měl být přeskočen nebo testovací prostředí předem připraveno.

When: akce

Blok When popisuje jedinou událost, která zahajuje testované chování. Může to být volání metody, stisknutí tlačítka, obdržení oznámení nebo odpovědi od serveru. Klíčové pravidlo — jeden When na scénář. Pokud je třeba zkontrolovat posloupnost akcí, vytvoří se samostatné scénáře, ne řetěz When.

// Given: vytváříme testovací data
val user = User(email = "test@example.com", balance = 500.0)
val product = Product(price = 150.0)

// When: provádíme akci
val result = PurchaseUseCase().buy(user, product)

// Then: kontrolujeme výsledek
assertEquals(PurchaseResult.Success, result)
assertEquals(350.0, user.balance)

Then: očekávaný výsledek

Blok Then kontroluje, zda systém přešel do očekávaného stavu. To zahrnuje: návratové hodnoty, změny stavu objektů, volání externích služeb (prostřednictvím mock ověření) a změny UI. Každý blok Then může obsahovat několik kontrol, ale všechny se vztahují k jedné akci.

Given-When-Then a Arrange-Act-Assert

Given-When-Then a Arrange-Act-Assert (AAA) — jsou dvě varianty stejného třídílného vzoru, ale s odlišným cílovým publikem. Pochopení jejich rozdílů pomáhá vybrat správný formát pro konkrétní úkol.

Kdy použít Given-When-Then

Vzor Given-When-Then je optimální pro scénáře, které jsou diskutovány s klientem nebo analytikem: akceptační kritéria funkcí, scénáře použití, regresní kontroly. Gherkin syntaxe umožňuje psát takové scénáře bez znalosti programování.

Kdy použít Arrange-Act-Assert

Arrange-Act-Assert — je přirozenou volbou pro unit testy, které kontrolují konkrétní metodu nebo třídu. Formát AAA nevyžaduje další frameworky a funguje v jakémkoli programovacím jazyce. Pro vývoj iOS Apple doporučuje AAA v dokumentaci XCTest (2024).

Příklady scénářů v Kotlinu

Podívejme se na praktické příklady Given-When-Then v Kotlinu pro Android aplikaci. První příklad — testování nákupního košíku pomocí MockK. Druhý — test logiky push oznámení.

Příklad 1: nákupní košík

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)
    }
}

Příklad 2: push oznámení s korutinami

Druhý příklad demonstruje Given-When-Then s asynchronním kódem. Zde Given nastavuje stav Firebase Cloud Messaging, When — přijetí push oznámení, Then — kontrolu zpracování.

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)
    }
}

Příklad 3: Gherkin scénář pro autorizaci

Třetí příklad — BDD scénář v Gherkinu, ukazující Given-When-Then v kontextu akceptačních testů:

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

Nejlepší postupy psaní scénářů

Efektivní použití Given-When-Then vyžaduje dodržování několika osvědčených postupů. Ty zajišťují čitelnost, udržovatelnost a automatizovatelnost scénářů.

Jeden When na scénář

Přísné pravidlo: jeden scénář — jedna akce. Pokud je třeba zkontrolovat posloupnost několika When, vytvořte několik scénářů, kde výsledek předchozího se stane předpokladem následujícího. To činí scénář atomickým a srozumitelným.

Vyhněte se konkrétním datům v Given

Given by měl popisovat podstatu, ne konkrétní čísla. Místo „Given uživatel Ivanov se zůstatkem 500 rublů” — „Given uživatel s dostatečným zůstatkem”. Konkrétní data se přesunou do Scenario Outline s tabulkou Examples. To činí scénář univerzálním a znovupoužitelným.

• Pište Then jako měřitelná tvrzení — „uživatel by měl vidět přihlašovací obrazovku”, ne „uživatel by měl být přesměrován”
• Používejte And pro podobné kroky — pokud je potřeba několik Given, spojte je přes And, nevytvářejte druhý Given
• Nemíchejte úrovně abstrakce — Given-When-Then by měl být na stejné úrovni: buď obchodní, nebo technické, ne promíchaně
• Dokumentujte důvod scénáře — komentář na začátku .feature souboru s popisem obchodního pravidla pomáhá kontextu

Given-When-Then v CI/CD pipeline

Integrace scénářů Given-When-Then do pipeline průběžné integrace je mění z dokumentace v ochranu proti regresím. Každý merge request v mobilním projektu automaticky spouští BDD scénáře a blokuje sloučení při selhání alespoň jednoho scénáře.

Automatické spouštění scénářů

BDD scénáře na Cucumber pro Android se spouštějí prostřednictvím Gradle úkolu ./gradlew cucumber. Pro iOS (Quick/Nimble) — přes xcodebuild test. V CI systémech (GitHub Actions, GitLab CI, Bitrise) se BDD testy provádějí na emulátorech nebo skutečných zařízeních. Sestava je generována v HTML formátu, srozumitelném pro manažery: zelené scénáře — úspěch, červené — neúspěch s uvedením kroku.

Živá dokumentace v repozitáři

Soubory .feature jsou uloženy v repozitáři vedle kódu a procházejí code review. Analytik vytváří merge request s novými scénáři před zahájením vývoje (BDD-first). Vývojář píše step definitions a implementaci, aby tyto scénáře zezelenaly. Když všechny scénáře procházejí — funkcionalita je hotová. Tento přístup, popsaný v knize Gojko Adzice „Specification by Example” (2011), mění požadavky na spustitelný artefakt.