Given-When-Then: що це, структура сценаріїв та приклади

Що таке Given-When-Then?

Given-When-Then — це шаблон опису поведінки, вперше сформульований Dan North у 2006 році як частина методології Behavior-Driven Development. Шаблон вирішує проблему неструктурованих описів тестових сценаріїв, які часто містять суміш передумов, дій та перевірок у довільному порядку.

Основна ідея шаблону — розділення відповідальності між трьома блоками. Кожен блок відповідає рівно за один аспект сценарію: стан до, подію під час і перевірку після. Це робить сценарій читабельним, перевірюваним і автоматизованим. За даними дослідження розробників фреймворку Cucumber (2024), сценарії, що суворо дотримуються шаблону Given-When-Then, потребують на 42% менше часу на розуміння новим членом команди.

Походження шаблону

Dan North запозичив ідею тричастинної структури з формулювання тестів у TDD та методології Test-by-Example (створеної Brian Marick). Маррік запропонував описувати вимоги через приклади (examples), які одночасно слугують тестами. Given-When-Then формалізував цю ідею, перетворивши неструктуровані приклади на повторюваний шаблон.

Сфера застосування

Шаблон Given-When-Then застосовується не лише в BDD-сценаріях на Gherkin, а й у звичайних модульних тестах на JUnit, XCTest та інших фреймворках. Коментарі в коді, що розділяють тест на три блоки, — поширена практика для покращення читабельності тестової бази. Google рекомендує цей підхід у своїй книзі «Software Engineering at Google» (2020).

Структура трьох блоків

Кожен блок Given-When-Then має суворо визначену семантику та правила наповнення. Порушення цих правил призводить до сценаріїв, які складно автоматизувати або зрозуміти.

Given: передумови

Блок Given описує стан системи до виконання тестованої дії. Він включає: існуючі об'єкти (користувач, замовлення, налаштування), активні стани (авторизований, підключений до мережі), а також початкові значення даних. Кожен Given має бути перевірюваним — якщо стан системи не відповідає Given, сценарій має бути пропущений або попередньо підготовлено тестове середовище.

When: дія

Блок When описує єдину подію, яка ініціює тестовану поведінку. Це може бути виклик методу, натискання кнопки, отримання сповіщення або відповіді від сервера. Ключове правило — один When на сценарій. Якщо потрібно перевірити послідовність дій — створюються окремі сценарії, а не ланцюжок When.

// Given: створюємо тестові дані
val user = User(email = "test@example.com", balance = 500.0)
val product = Product(price = 150.0)

// When: виконуємо дію
val result = PurchaseUseCase().buy(user, product)

// Then: перевіряємо результат
assertEquals(PurchaseResult.Success, result)
assertEquals(350.0, user.balance)

Then: очікуваний результат

Блок Then перевіряє, що система перейшла в очікуваний стан. Це включає: значення, що повертаються, зміни стану об'єктів, виклики зовнішніх сервісів (через mock-верифікацію), а також UI-зміни. Кожен Then-блок може містити кілька перевірок, але всі вони стосуються однієї дії.

Given-When-Then і Arrange-Act-Assert

Given-When-Then і Arrange-Act-Assert (AAA) — це два варіанти одного й того ж тричастинного шаблону, але з різною цільовою аудиторією. Розуміння їхніх відмінностей допомагає вибрати правильний формат для конкретного завдання.

Коли використовувати Given-When-Then

Шаблон Given-When-Then оптимальний для сценаріїв, які обговорюються із замовником або аналітиком: acceptance criteria функцій, сценарії використання, регресійні перевірки. Синтаксис Gherkin дозволяє писати такі сценарії без знання програмування.

Коли використовувати Arrange-Act-Assert

Arrange-Act-Assert — природний вибір для модульних тестів, які перевіряють конкретний метод або клас. Формат AAA не потребує додаткових фреймворків і працює в будь-якій мові програмування. Для iOS-розробки Apple рекомендує AAA у документації XCTest (2024).

Приклади сценаріїв на Kotlin

Розглянемо практичні приклади Given-When-Then на Kotlin для Android-додатку. Перший приклад — тестування кошика покупок з використанням MockK. Другий — тест логіки push-сповіщень.

Приклад 1: кошик покупок

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

Приклад 2: push-сповіщення з корутинами

Другий приклад демонструє Given-When-Then з асинхронним кодом. Тут Given задає стан Firebase Cloud Messaging, When — отримання push-сповіщення, Then — перевірку обробки.

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

Приклад 3: Gherkin-сценарій для авторизації

Третій приклад — BDD-сценарій на Gherkin, що показує Given-When-Then у контексті приймальних тестів:

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

Найкращі практики написання сценаріїв

Ефективне застосування Given-When-Then потребує дотримання кількох перевірених практик. Вони забезпечують читабельність, підтримуваність і автоматизованість сценаріїв.

Один When на сценарій

Жорстке правило: один сценарій — одна дія. Якщо потрібно перевірити послідовність із кількох When, створіть кілька сценаріїв, де результат попереднього стає передумовою наступного. Це робить сценарій атомарним і зрозумілим.

Уникайте конкретних даних у Given

Given має описувати суть, а не конкретні цифри. Замість «Given користувач Іванов із балансом 500 гривень» — «Given користувач із достатнім балансом». Конкретні дані виносяться в Scenario Outline з таблицею Examples. Це робить сценарій універсальним і перевикористовуваним.

• Пишіть Then як вимірювані твердження — «користувач повинен побачити екран входу», а не «користувач повинен бути перенаправлений»
• Використовуйте And для однотипних кроків — якщо потрібно кілька Given, об'єднайте їх через And, не створюйте другий Given
• Не змішуйте рівні абстракції — Given-When-Then має бути на одному рівні: або бізнесовому, або технічному, але не впереміш
• Документуйте причину сценарію — коментар на початку .feature файлу з описом бізнес-правила допомагає контексту

Given-When-Then у CI/CD пайплайні

Інтеграція Given-When-Then сценаріїв у пайплайн безперервної інтеграції перетворює їх із документації на захист від регресій. Кожен merge request у мобільному проєкті автоматично запускає BDD-сценарії та блокує злиття при падінні хоча б одного сценарію.

Автоматичний запуск сценаріїв

BDD-сценарії на Cucumber для Android запускаються через Gradle-таск ./gradlew cucumber. Для iOS (Quick/Nimble) — через xcodebuild test. У CI-системах (GitHub Actions, GitLab CI, Bitrise) BDD-тести виконуються на емуляторах або реальних пристроях. Звіт формується у HTML-форматі, зрозумілому менеджерам: зелені сценарії — здано, червоні — провал із зазначенням кроку.

Жива документація в репозиторії

.feature файли зберігаються в репозиторії поруч із кодом і проходять code review. Аналітик створює merge request із новими сценаріями до початку розробки (BDD-first). Розробник пише step definitions і реалізацію, щоб ці сценарії стали зеленими. Коли всі сценарії проходять — функціональність готова. Такий підхід, описаний у книзі Gojko Adzic «Specification by Example» (2011), перетворює вимоги на виконуваний артефакт.