Given-When-Then: co to jest, struktura scenariuszy i przykłady

Co to jest Given-When-Then?

Given-When-Then — to wzorzec opisywania zachowania, po raz pierwszy sformułowany przez Dana Northa w 2006 roku jako część metodologii Behavior-Driven Development. Wzorzec rozwiązuje problem nieustrukturyzowanych opisów scenariuszy testowych, które często zawierają mieszankę warunków wstępnych, akcji i sprawdzeń w dowolnej kolejności.

Główną ideą wzorca jest podział odpowiedzialności między trzy bloki. Każdy blok odpowiada za dokładnie jeden aspekt scenariusza: stan przed, zdarzenie w trakcie i sprawdzenie po. To czyni scenariusz czytelnym, weryfikowalnym i automatyzowalnym. Według badań deweloperów frameworka Cucumber (2024), scenariusze ściśle stosujące wzorzec Given-When-Then wymagają o 42% mniej czasu na zrozumienie przez nowego członka zespołu.

Pochodzenie wzorca

Dan North zapożyczył ideę trójczęściowej struktury z formulation of tests w TDD i metodologii Test-by-Example (stworzonej przez Briana Maricka). Marick zaproponował opisywanie wymagań przez przykłady (examples), które jednocześnie służą jako testy. Given-When-Then sformalizował tę ideę, przekształcając nieustrukturyzowane przykłady w powtarzalny wzorzec.

Obszar zastosowania

Wzorzec Given-When-Then jest stosowany nie tylko w scenariuszach BDD w Gherkin, ale także w zwykłych testach jednostkowych w JUnit, XCTest i innych frameworkach. Komentarze w kodzie, dzielące test na trzy bloki, to powszechna praktyka poprawiająca czytelność bazy testowej. Google zaleca to podejście w swojej książce „Software Engineering at Google” (2020).

Struktura trzech bloków

Każdy blok Given-When-Then ma ściśle określoną semantykę i reguły wypełniania. Naruszenie tych reguł prowadzi do scenariuszy, które trudno zautomatyzować lub zrozumieć.

Given: warunki wstępne

Blok Given opisuje stan systemu przed wykonaniem testowanej akcji. Obejmuje: istniejące obiekty (użytkownik, zamówienie, ustawienia), aktywne stany (zalogowany, podłączony do sieci), a także początkowe wartości danych. Każdy Given powinien być weryfikowalny — jeśli stan systemu nie odpowiada Given, scenariusz powinien zostać pominięty lub środowisko testowe powinno zostać wcześniej przygotowane.

When: akcja

Blok When opisuje pojedyncze zdarzenie, które inicjuje testowane zachowanie. Może to być wywołanie metody, naciśnięcie przycisku, otrzymanie powiadomienia lub odpowiedzi z serwera. Kluczową zasadą jest jeden When na scenariusz. Jeśli trzeba sprawdzić sekwencję akcji — tworzone są osobne scenariusze, a nie łańcuch When.

// Given: tworzymy dane testowe
val user = User(email = "test@example.com", balance = 500.0)
val product = Product(price = 150.0)

// When: wykonujemy akcję
val result = PurchaseUseCase().buy(user, product)

// Then: sprawdzamy rezultat
assertEquals(PurchaseResult.Success, result)
assertEquals(350.0, user.balance)

Then: oczekiwany rezultat

Blok Then sprawdza, czy system przeszedł w oczekiwany stan. Obejmuje to: zwracane wartości, zmiany stanu obiektów, wywołania zewnętrznych serwisów (przez mock-weryfikację), a także zmiany UI. Każdy blok Then może zawierać wiele sprawdzeń, ale wszystkie odnoszą się do jednej akcji.

Given-When-Then a Arrange-Act-Assert

Given-When-Then i Arrange-Act-Assert (AAA) — to dwa warianty tego samego trójczęściowego wzorca, ale z różną grupą docelową. Zrozumienie ich różnic pomaga wybrać odpowiedni format dla konkretnego zadania.

Kiedy stosować Given-When-Then

Wzorzec Given-When-Then jest optymalny dla scenariuszy, które są omawiane z klientem lub analitykiem: kryteria akceptacji funkcji, scenariusze użycia, sprawdzenia regresyjne. Składnia Gherkin pozwala pisać takie scenariusze bez znajomości programowania.

Kiedy stosować Arrange-Act-Assert

Arrange-Act-Assert — to naturalny wybór dla testów jednostkowych, które sprawdzają konkretną metodę lub klasę. Format AAA nie wymaga dodatkowych frameworków i działa w każdym języku programowania. Do rozwoju iOS Apple zaleca AAA w dokumentacji XCTest (2024).

Przykłady scenariuszy w Kotlin

Rozważmy praktyczne przykłady Given-When-Then w Kotlin dla aplikacji Android. Pierwszy przykład — testowanie koszyka zakupów z użyciem MockK. Drugi — test logiki powiadomień push.

Przykład 1: koszyk zakupów

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

Przykład 2: powiadomienia push z corutinami

Drugi przykład demonstruje Given-When-Then z kodem asynchronicznym. Tutaj Given określa stan Firebase Cloud Messaging, When — otrzymanie powiadomienia push, Then — sprawdzenie przetwarzania.

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

Przykład 3: scenariusz Gherkin dla autoryzacji

Trzeci przykład — scenariusz BDD w Gherkin, pokazujący Given-When-Then w kontekście testów akceptacyjnych:

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

Najlepsze praktyki pisania scenariuszy

Efektywne stosowanie Given-When-Then wymaga przestrzegania kilku sprawdzonych praktyk. Zapewniają one czytelność, utrzymywalność i automatyzowalność scenariuszy.

Jeden When na scenariusz

Sztywna zasada: jeden scenariusz — jedna akcja. Jeśli trzeba sprawdzić sekwencję kilku When, utwórz kilka scenariuszy, gdzie rezultat poprzedniego staje się warunkiem wstępnym następnego. To czyni scenariusz atomowym i zrozumiałym.

Unikaj konkretnych danych w Given

Given powinien opisywać istotę, a nie konkretne liczby. Zamiast „Given użytkownik Iwanow z saldem 500 rubli” — „Given użytkownik z wystarczającym saldem”. Konkretne dane są przenoszone do Scenario Outline z tabelą Examples. To czyni scenariusz uniwersalnym i wielokrotnego użytku.

• Pisz Then jako mierzalne twierdzenia — „użytkownik powinien zobaczyć ekran logowania”, a nie „użytkownik powinien zostać przekierowany”
• Używaj And dla podobnych kroków — jeśli potrzeba kilka Given, połącz je przez And, nie twórz drugiego Given
• Nie mieszaj poziomów abstrakcji — Given-When-Then powinien być na jednym poziomie: biznesowym lub technicznym, ale nie na zmianę
• Dokumentuj powód scenariusza — komentarz na początku pliku .feature z opisem reguły biznesowej pomaga w kontekście

Given-When-Then w pipeline CI/CD

Integracja scenariuszy Given-When-Then z pipeline ciągłej integracji przekształca je z dokumentacji w ochronę przed regresjami. Każde merge request w projekcie mobilnym automatycznie uruchamia scenariusze BDD i blokuje scalenie w przypadku upadku choćby jednego scenariusza.

Automatyczne uruchamianie scenariuszy

Scenariusze BDD w Cucumber dla Androida są uruchamiane przez Gradle task ./gradlew cucumber. Dla iOS (Quick/Nimble) — przez xcodebuild test. W systemach CI (GitHub Actions, GitLab CI, Bitrise) testy BDD są wykonywane na emulatorach lub rzeczywistych urządzeniach. Raport jest generowany w formacie HTML, zrozumiałym dla menedżerów: zielone scenariusze — zaliczone, czerwone — porażka z wskazaniem kroku.

Żywa dokumentacja w repozytorium

Pliki .feature są przechowywane w repozytorium obok kodu i przechodzą code review. Analityk tworzy merge request z nowymi scenariuszami przed rozpoczęciem rozwoju (BDD-first). Deweloper pisze step definitions i implementację, aby te scenariusze stały się zielone. Gdy wszystkie scenariusze przechodzą — funkcjonalność jest gotowa. Takie podejście, opisane w książce Gojko Adzica „Specification by Example” (2011), przekształca wymagania w wykonywalny artefakt.