BDD і Gherkin: обіцянки і реальність

Зміст

BDD і Gherkin продають як срібну кулю: пишете сценарії людською мовою «Given… When… Then», бізнес їх читає, тестувальник автоматизує, і в команди зʼявляється єдина , яка ніколи не бреше. На практиці ж чимало команд отримують зайвий шар над UI-тестами: ті самі крихкі кліки, тільки тепер загорнуті в англійські речення, які ніхто, крім AQA, не відкриває. Обіцянка й реальність розходяться не тому, що інструмент поганий, а тому, що плутають дві різні речі — практику й формат запису.

Пастка тут проста: на питання «Що таке BDD?» слабкий кандидат відповідає «це коли пишемо тести на Gherkin через Cucumber». Сильний почне з того, що BDD — це передусім розмова, а Gherkin — лише спосіб її зафіксувати. Ця глава — про те, де межа між обіцянкою і реальністю, і як не платити за синтаксис, не отримавши вигоди.

BDD — це практика співпраці, а не синтаксис

BDD (Behavior-Driven Development, розробка через поведінку) виросла з TDD у середині 2000-х як спроба Дена Норта (Dan North) прибрати з TDD слово «тест», яке збивало новачків з пантелику. Ідея: описувати не тести, а очікувану поведінку системи прикладами, і робити це разом — до написання коду.

Центральний ритуал BDD — розмова, яку офіційна дока Cucumber називає «три амігос» (The Three Amigos): це зустріч, що перетворює історію користувача на сценарії Gherkin, і голосів у ній «щонайменше три». Дока розписує роли поіменно: представник бізнесу (product owner) відповідає за і вирішує, що в нього входить; тестувальник генерує сценарії й граничні випадки та питає «як це зламається»; розробник додає кроки й думає про механіку виконання. Число «три» й одноразовість зустрічі дока прямо називає не обмеженням: «there is no reason to limit these meetings to three people—or to hold only one such meeting at the beginning of the project».

Ось ключ до всієї глави: цінність BDD створюється в розмові, а не в текстовому файлі. Це не наша інтерпретація — дока Cucumber ставить документацію й автотести на місце «nice side-effects», а справжньою метою називає робоче ПО, до якого швидше за все веде розмова. Якщо команда пропустила обговорення й просто написала Gherkin постфактум, «щоб було по-модному», вона заплатила повну ціну інструмента, не отримавши головного — вирівняного розуміння й ранньої ловитви непорозумінь. Формалізована техніка такої розмови — : беруть історію (жовта картка), виписують правила (rules, сині), під кожне — приклади (examples, зелені), а незрозуміле складають у стос запитань (questions, червоні), «so we can move on with the conversation». За деталями офіційна дока посилається на блог Метта Вінна (Matt Wynne) — авторства техніки вона при цьому не приписує нікому.

Одне уточнення, щоб не переказувати чуже своїми словами: теза «стос питань окупає зустріч» — наш висновок, а не твердження доки. Дока каже лише, що питання фіксують, щоб не блокувати розмову. Найближче до нашої тези вона підходить в іншому місці, і про discovery загалом: структурована розмова «may also reveal gaps in our understanding, where we need more information before we know what to do».

Тому коректне визначення для співбесіди: BDD — це практика співпраці навколо конкретних прикладів поведінки; Gherkin, Cucumber, feature-файли — лише інструменти, які цю практику підтримують, але не замінюють.

Діаграма показує головне непорозуміння: Gherkin (крок C) — лише один вузол циклу. Команди, що впроваджують «BDD», часто стартують одразу з C, пропустивши A і B, — і дивуються, чому вигоди немає.

Given–When–Then: анатомія сценарію

Gherkin — це структурована майже-природна мова для запису прикладів. Її кістяк — три ключові слова:

Given — контекст, стан світу до події (). «Given користувач залогінений».
When — подія або дія, що запускає поведінку. В ідеалі одна. «When він додає товар у кошик».
Then — очікуваний спостережуваний результат. «Then у кошику один товар».

Кроки зчіплюють словами And і But. Спільний для всіх сценаріїв контекст виносять у Background. Приклад feature-файлу:

Feature: Кошик

  Background:
    Given користувач залогінений

  Scenario: Додавання товару в порожній кошик
    Given кошик порожній
    When користувач додає товар "Клавіатура"
    Then у кошику 1 товар
    And сума кошика дорівнює ціні "Клавіатури"

Структура невипадкова: Given–When–Then один в один лягає на Arrange–Act–Assert з глави «Анатомія автотесту». Given — це підготовка стану, When — дія, Then — перевірка. Звідси й дисципліна, яку перевіряють на рев'ю: у Given не роблять , у Then не тиснуть кнопок. Один сценарій — одна поведінка, а не десять кліків «за компанію».

Для параметризації є Scenario Outline з таблицею Examples — це той самий data-driven тест (див. главу про тест-дані):

Scenario Outline: Валідація пароля при реєстрації
  When користувач реєструється з паролем "<password>"
  Then система показує "<result>"

  Examples:
    | password    | result             |
    | short       | Пароль закороткий  |
    | goodpass123 | Реєстрація успішна |

Одне застереження термінології: Gherkin — це синтаксис і мова; Cucumber, SpecFlow, Behave, вбудований BDD у CodeceptJS — це інструменти, які цю мову виконують. Given–When–Then можна вживати як формат (acceptance criteria) навіть без жодного інструмента — просто в тікеті Jira.

Imperative проти declarative

Ось де вирішується доля всієї затії. Обидва слова — терміни офіційної доки Cucumber, і правило вона формулює одним рядком: сценарій описує задуману поведінку системи, а не реалізацію — «it should describe what, not how». Один і той самий сценарій можна написати двома способами.

Імперативний (imperative) — описує кроки інтерфейсу:

Scenario: Логін (імперативно)
  Given користувач на сторінці "/login"
  When він вводить "user@test.io" у поле "email"
  And вводить "Qwerty123" у поле "password"
  And натискає кнопку "Увійти"
  Then він бачить заголовок "Мій профіль"

Декларативний (declarative) — описує намір, а «як» ховає в код кроків:

Scenario: Логін (декларативно)
  Given зареєстрований користувач
  When він входить у систему
  Then він потрапляє у свій профіль

Різниця не косметична. крихкий: перейменували поле, змінили верстку форми — і треба правити текст, який мав би читати бізнес. Він багатослівний і фактично дублює page object у прозі. Головне — він нечитабельний для нетехнічного читача: продакт-менеджер не хоче знати про поле «email», він хоче знати, що «користувач входить у систему».

стабільний: зміна UI зачіпає лише (step definition), а не сам сценарій. Так це формулює й дока: «when the implementation of a feature changes, you'll only need to change the process steps behind the scenes». Він читається як вимога, переживає редизайн і не тече деталями реалізації. Правило-орієнтир: у feature-файлі — мова бізнесу й наміри; уся механіка кліків і — нижче, у коді кроків.

Але одразу зніміть із декларативності ореол догми — і не приписуйте догму джерелу. Дока подає імперативний стиль без осуду: «Imperative tests communicate details, and in some contexts this style of test is appropriate», і мінус називає конкретний — такі тести дорожчі в підтримці, бо привʼязані до механіки поточного UI.

Нюанс для сеньйора — і тут ми виходимо за межі джерела, тож кажемо це прямо: застереження «занадто декларативно теж погано» — наше, у доці Cucumber його немає. Дока попереджає про протилежний надмір (забагато деталей реалізації в сценарії), а про надмір абстракції не говорить. Наше спостереження таке: якщо весь сценарій це «When усе працює / Then все добре», він нічого конкретного не перевіряє — читається гарно, а тестова цінність нульова. Баланс: один сценарій — один бізнес-намір із конкретним, але не покроковим результатом.

Коли Gherkin виправданий, а коли це податок

Тепер чесно про ціну. Gherkin додає (indirection): feature-файл не виконується сам — кожен рядок треба привʼязати до функції-кроку, розпарсити параметри, підтримувати цей glue-код. Дебажити стає важче: падіння в кроці «When він входить у систему» доводиться розкручувати через кілька рівнів, а не читати прямо в тесті.

Кожна стрілка — місце, де може зламатися привʼязка й де губиться слід під час дебагу. Звичайний Playwright-тест має на один рівень менше: він одразу починається з рівня B.

Ця ціна окупається за конкретних умов:

Є реальний нетехнічний читач. Продакт, аналітик, комплаєнс, замовник справді відкривають і читають сценарії або беруть участь у їх написанні. Це головна умова.
Розмова відбувається насправді. Команда практикує «три амігос» / example mapping, і feature-файли народжуються з обговорення, а не пишуться AQA наодинці.
Критерії приймання — спільний контракт. Given–When–Then живе у історії, а не тільки в тестовому репозиторії.

І дзеркально — коли Gherkin стає чистим податком:

Технічна AQA-команда пише сценарії сама для себе, і жоден нетехнічний колега їх ніколи не відкриває. Тоді англійський прошарок над Playwright не додає нічого, крім роботи: звичайний test('користувач входить у систему') з гарною назвою — це вже документація, без витрат на парсинг Gherkin.
Сценарії імперативні (див. вище) — ви отримали крихкість UI-тестів плюс накладні витрати BDD і жодної читабельності натомість.

Просте правило: якщо прибрати Gherkin і ніхто поза командою автоматизації цього не помітить — він вам не потрібен.

Living documentation: коли документація справді жива

Найпринадніша обіцянка BDD — жива документація (living documentation). Термін в офіційній доці є, але — важлива деталь — стоїть він там у лапках і без окремого означення: «Declarative scenarios read better as "living documentation"». Тобто дока звʼязує «живість» саме з декларативним стилем, а не проголошує окрему сутність.

Сам механізм дока формулює в іншому місці й без лапок — у переліку трьох складових BDD: «Producing system documentation that is automatically checked against the system's behaviour». Ось звідки логіка: сценарії водночас і опис поведінки, і виконуваний тест. Якщо поведінка системи зміниться, а сценарій — ні, тест впаде. Отже, документація не може тихо застаріти: розбіжність між нею і кодом миттєво стає червоним . Це радикально відрізняється від Confluence-сторінки, яку востаннє оновлювали два релізи тому.

Інструменти BDD генерують із прогону читабельні звіти — по суті специфікацію системи, де видно, які сценарії проходять (див. главу «Звітність» про звіт як продукт). Механіка привʼязки Gherkin-рядків до коду (step definitions, World, хуки в CucumberJS) — окрема тема інструментів, її розбирає відповідна глава розділу про інструменти автоматизації; тут важливий принцип, а не синтаксис степів.

Але «жива» вона лише за трьох умов — і це вже наш перелік, зібраний із практики, а не цитата доки:

Сценарії декларативні й читабельні — інакше це «жива» стіна кліків, яку нехтоно читати.
Її хтось реально читає — документація без читача мертва за визначенням.
зелена — набір, де половина сценаріїв у @skip або стабільно червоні, документує не систему, а занедбаність команди.

Living documentation — не безкоштовний наслідок Gherkin, а результат дисципліни. Той самий (глава «Флакі-тести») у BDD-обгортці шкодить подвійно: він і ламає гейт, і підриває довіру до документа, який мав бути джерелом істини.

Типові помилки

Виглядає як «ми впровадили BDD», а насправді — купили Cucumber і пишемо Gherkin постфактум наодинці. Без «трьох амігос» це не BDD, а дорожчий спосіб писати ті самі тести.
Виглядає як читабельний сценарій, а насправді — імперативний переказ кліків: «вводить email, натискає кнопку». Бізнес його не читатиме, а ви отримали зайвий шар над крихким UI-тестом.
Виглядає як жива документація, а насправді — 30% сценаріїв у @ignore і ніхто їх не відкриває місяцями. Документація, яку не читають і не тримають зеленою, мертва.
Виглядає як економія (один сценарій — багато кроків), а насправді — «сценарій-простирадло» з десятком When підряд: тестує все й нічого, падає з десяти причин, порушує атомарність.
Виглядає як переваги Gherkin, а насправді — технічна команда пише сценарії сама для себе. Прибери прошарок — і describe/it з гарними назвами дасть ту саму документацію дешевше.
Виглядає як повторне використання, а насправді — надто узагальнені кроки-«швейцарський ніж» на кшталт «When я натискаю "X"», з яких складають будь-що. Це не BDD-словник домену, а прихований imperative через чорний хід.

Підсумок

BDD — це практика співпраці навколо прикладів поведінки; Gherkin і Cucumber — лише інструменти запису. Цінність народжується в розмові, а не у feature-файлі.
Given–When–Then = Arrange–Act–Assert у прозі: Given — стан, When — одна дія, Then — перевірка; асертам не місце в Given, діям — у Then.
Declarative (намір) перемагає imperative (кліки): стабільніший до змін UI, читабельний для бізнесу, ховає «як» у кроки коду.
Gherkin окупається лише за реального нетехнічного читача й живої практики «трьох амігос»; для технічної команди, що пише для себе, це податок понад звичайні тести.
Living documentation жива тільки поки сценарії декларативні, зелені й хтось їх читає; інакше це мертвий текст із накладними витратами. Ці три умови — наш перелік; джерельним у ньому є лише механізм «документації, що автоматично перевіряється проти поведінки».

Можливі питання

«Що таке BDD?» Інтерв'юер перевіряє, чи не зводите ви BDD до інструмента. Сильна відповідь починається з «це практика співпраці, розмова про приклади поведінки до коду», і лише потім згадує Gherkin як формат запису.
«Навіщо Given–When–Then, чим це краще за звичайний тест?» Дивляться, чи бачите ви звʼязок з AAA і читабельність для нетехнічного читача, а не просто «так прийнято».
«Imperative vs declarative сценарій — у чому різниця й що краще?» Класика для middle. Очікують приклад обох і аргумент про стабільність та аудиторію, а не догму «declarative завжди» — офіційна дока її й не встановлює, вона прямо , що «in some contexts this style of test is appropriate».
«Коли ви НЕ радите BDD?» Найпоказовіше питання: зрілий кандидат чесно каже, що для суто технічної команди без нетехнічних читачів Gherkin — накладні витрати. Незрілий вважає BDD універсальним добром.
«Що таке living documentation і чому вона часто не працює?» Дивляться на розуміння умов: декларативність, зелена сюїта, реальний читач; і на чесність про типовий провал.

Джерела

BDD — це практика співпраці, а не синтаксис

Dan North — Introducing BDD — першоджерело терміна: BDD зʼявився як відповідь на проблеми навчання TDD (де почати, що тестувати, як називати тести), а не як спосіб писати тести природною мовою.
Cucumber Docs — Behaviour-Driven Development — три практики поіменно (Discovery, Formulation, Automation) з жорстким порядком, і пряма теза: документація й автотести — побічні ефекти BDD, а мета — робоче ПЗ через розмови.
Cucumber Docs — Who does what? — «три амігос» це зустріч, а не троє людей: голосів «щонайменше три» (скоуп, сценарії й межові випадки, здійсненність), і дока радить не зводити зустріч до трьох і повторювати її.
Cucumber Docs — Example Mapping — техніка тієї самої розмови до взяття історії в роботу: story → rules → examples → questions.
ISTQB® CTAL-TAE Syllabus v2.0 — пастка, названа каноном прямо: команди зводять BDD до «тестів природною мовою» й не залучають бізнес і розробників у сам підхід.

Given–When–Then: анатомія сценарію

Cucumber — Gherkin Reference — нормативна механіка: кожен непорожній рядок має починатися з ключового слова, перше ключове слово документа must бути Feature, Given описує контекст і не описує взаємодію користувача, Then перевіряє спостережуваний вихід — і пряма настанова опиратися спокусі перевіряти в Then базу даних.
Martin Fowler — GivenWhenThen — розведення інструмента й мови (Cucumber — інструмент, Gherkin — його DSL) і те, що Given/When/Then є переформулюванням , вживаним і поза BDD-інструментами.
Dan North — Introducing BDD — чому фрагменти мають бути дрібними: це умова того, щоб критерій приймання став виконуваним кодом, а кроків закладене в задум від початку.

Imperative проти declarative

Cucumber Docs — Writing better Gherkin — обидва терміни офіційні, різниця сформульована як «what, not how»; декларативний стиль робить сценарії легшими в підтримці й менш крихкими, бо при зміні реалізації правиться код кроків, а не сценарій. Імперативний стиль подано без осуду: «in some contexts this style of test is appropriate».
Cucumber — Gherkin Reference — інструменти, якими прибирають шум замість імперативних кроків: Background проти повторення однакових Given і Scenario Outline для того самого сценарію на різних комбінаціях значень.

Коли Gherkin виправданий, а коли це податок

ISTQB® CTAL-TAE Syllabus v2.0 — обидві чаші терезів у формулюванні канону: вигоди (комунікація між розробниками, бізнесом і тестувальниками; сценарії як тест-кейси; застосовність на різних рівнях піраміди) і ціна — реалізація й підтримка кроків природною мовою названа складною задачею, а надто складні кроки роблять дебаг важким і дорогим; негативні сценарії й межові випадки BDD не покриває сам.
Cucumber Docs — Behaviour-Driven Development — і те, звідки береться віддача: без опанованого Discovery решта практик її не дають.

Living documentation: коли документація справді жива

Cucumber Docs — Behaviour-Driven Development — механізм «живості» названо окремим пунктом серед трьох складових BDD: «Producing system documentation that is automatically checked against the systemʼs behaviour».
Cucumber Docs — Writing better Gherkin — сам термін офіційний, але поданий у лапках і без означення: «Declarative scenarios read better as "living documentation"» — тобто це радше властивість стилю, ніж окремий артефакт.

Відео до теми

що не так з BDD? (керована поведінкою розробка)qa senpai | test automation

Донатний курсPlaywright — курс від автора каналу HOTtestingДоступ за донат на банку автора курсуДо курсу

Що таке BDD і чому неправильно зводити його до Gherkin?

BDD (Behavior-Driven Development, розробка через поведінку) — це передусім спосіб командної співпраці, а не набір ключових слів у файлі. Суть у тому, що бізнес, розробка й тестування разом розбирають майбутню фічу на конкретних прикладах поведінки ще до написання коду, і з цього народжується спільне розуміння. Gherkin, Cucumber, feature-файли — лише інструменти, які допомагають зафіксувати домовленість, але не створюють її. Тому відповідь «BDD — це коли пишемо тести на Gherkin» на співбесіді одразу видає слабкого кандидата: він переплутав практику з форматом запису. Головна цінність виникає в розмові про приклади, а текстовий сценарій — це вже її побічний продукт. Якщо команда пропустила обговорення й просто нагенерувала сценаріїв «щоб було модно», вона заплатила за інструмент, не отримавши головного.

Звідки взялося BDD і яку проблему TDD воно намагалося розвʼязати?

BDD виросло з TDD (Test-Driven Development) у середині 2000-х, коли Ден Норт (Dan North) помітив, що слово «тест» збиває новачків з пантелику. Люди застрягали на питанні «що і як тестувати», замість того щоб думати про очікувану поведінку системи. Ідея була в тому, щоб описувати не тести, а поведінку — прикладами й людською мовою, зрозумілою і бізнесу. Це зсунуло фокус з перевірки готового коду на прояснення вимог до його написання. Практичний наслідок: BDD природно тягне команду до розмови про приклади на ранньому етапі, коли непорозуміння ще дешево виправити.

Що таке «три амігос» і навіщо цей ритуал?

«Три амігос» (The Three Amigos) — термін офіційної доки Cucumber: зустріч, що перетворює історію користувача на сценарії Gherkin, із трьома голосами «щонайменше». Роли дока розписує поіменно: представник бізнесу (product owner) тримає і вирішує, що в нього входить; тестувальник генерує сценарії й граничні випадки та питає, як це зламається; розробник додає кроки й думає про механіку виконання. Цінність дока обґрунтовує різними перспективами: «each amigo sees the product from a different perspective». Тут варто бути точним у формулюванні мети: дока називає прямим результатом зустрічі саме сценарії, а тезу «сценарії — побічний ефект, головне спільне розуміння» вона робить в іншому місці, називаючи документацію й тести «nice side-effects». І число «три», і одноразовість дока прямо знімає: зустрічі радить повторювати й не обмежувати трьома людьми.

Що таке example mapping і чим корисний його «стос питань»?

— термін офіційної доки Cucumber: метод, що робить розмову про короткою й продуктивною, і робиться вона до того, як історію взяли в розробку. Беруть історію (жовта картка), виписують правила (rules, сині), під кожне правило підбирають конкретні приклади (examples, зелені), а все незрозуміле складають в окремий стос запитань (questions, червоні) — щоб можна було рухатися далі. Зупиняються, коли скоуп історії зрозумілий або скінчився час. Тезу «найцінніше тут — стос питань» варто подавати як власний висновок: дока її не робить, вона лише каже, що питання фіксують, аби не блокувати розмову; найближче до неї — зауваження про discovery загалом, що така розмова «may also reveal gaps in our understanding». Про авторство: дока посилається на блог Метта Вінна (Matt Wynne) за деталями, але авторства техніки нікому не приписує.

Як Given–When–Then співвідноситься з Arrange–Act–Assert?

Це та сама тришарова структура тесту, тільки в прозі. Given описує контекст і стан світу до події — це Arrange, підготовка. When — це подія чи дія, що запускає поведінку, і в ідеалі вона одна — це Act. Then — очікуваний спостережуваний результат — це Assert, перевірка. Практичний наслідок цієї відповідності — правило, яке ловлять на код-рев'ю: перевіркам не місце у Given, а натисканням кнопок і зміні стану — у Then. Один сценарій описує одну поведінку, а не ланцюжок з десяти дій «за компанію». Якщо кандидат бачить цей звʼязок, він розуміє, чому Gherkin структуровано саме так, а не просто «бо так прийнято».

Для чого потрібні Background і Scenario Outline?

Background виносить спільний для всіх сценаріїв контекст в одне місце, щоб не повторювати той самий Given у кожному сценарії — наприклад, «користувач залогінений». Scenario Outline розвʼязує іншу задачу: коли одну й ту саму поведінку треба перевірити на різних наборах даних, її записують один раз із плейсхолдерами, а самі дані виносять у таблицю Examples. По суті це data-driven тест засобами Gherkin: рядки таблиці стають окремими прогонами сценарію. Обидва механізми — про усунення дублювання, щоб сценарії лишалися читабельними. Плутати їх не варто: Background про спільну , Outline про параметризацію.

У чому різниця між Gherkin і Cucumber?

Це різні шари, які часто змішують. Gherkin — це синтаксис і майже-природна мова: ключові слова Given/When/Then, структура feature-файлу, правила його оформлення. Cucumber (а також SpecFlow, Behave, вбудований BDD у CodeceptJS) — це інструмент, який цю мову виконує: парсить рядки, звʼязує їх зі step-функціями, ганяє сценарії як тести. Практичний наслідок: Given–When–Then можна вживати взагалі без жодного інструмента — наприклад, як формат критеріїв приймання (acceptance criteria) прямо в тікеті Jira. Тобто мова існує окремо від рушія, і формулювання критеріїв через GWT не зобовʼязує вас тягнути Cucumber у проєкт.

Чим імперативний сценарій відрізняється від декларативного і що краще?

Імперативний (imperative) сценарій описує кроки інтерфейсу: «вводить email у поле, вводить пароль, натискає кнопку». Декларативний (declarative) описує намір: «користувач входить у систему», а «як саме» ховається у (step definition). Різниця не косметична, а вирішальна: крихкий — досить перейменувати поле чи змінити верстку, і доводиться редагувати той самий рядок, який нібито призначений для очей бізнесу; до того ж він нечитабельний для нетехнічного читача й фактично дублює у прозі. Декларативний стабільний до змін UI (правиться лише код кроку, не сценарій) і читається як вимога. Тому за замовчуванням орієнтир — декларативно, але без догми, і догми тут не встановлює саме джерело: дока прямо пише, що «in some contexts this style of test is appropriate» про імперативний стиль. У feature-файлі — мова бізнесу й наміри, а вся механіка кліків і живе нижче, у коді кроків.

Чи буває сценарій «занадто декларативним»?

Так — і одразу чесна дисклеймер-рамка: це наше застереження, в офіційній доці Cucumber його немає (вона попереджає про протилежний надмір — забагато деталей реалізації у сценарії). Тепер по суті: це друга крайність, про яку забувають. Якщо намір узагальнити до «When усе працює / Then все добре», сценарій читається красиво, але не перевіряє нічого конкретного — його тестова цінність нульова. Декларативність має ховати деталі реалізації, а не саму суть перевірки. Правильний баланс — сценарій навколо одного наміру домену, де результат конкретний, але не розписаний по кроках: не «вводить у поле email» і не «все ок», а щось на кшталт «потрапляє у свій профіль». Тобто читабельність не повинна коштувати визначеності: якщо зі сценарію не зрозуміло, що саме він гарантує, він марний незалежно від того, наскільки гарно звучить.

Які технічні накладні витрати додає Gherkin порівняно зі звичайним тестом?

Gherkin додає (indirection): feature-файл сам по собі не запускається — за кожним рядком має стояти функція-крок, яка розбирає параметри, і весь цей glue-код доводиться супроводжувати. Виходить довший ланцюжок: feature-файл → step definitions → page object чи API-клієнт → застосунок, і кожна стрілка — місце, де привʼязка може зламатися. Дебаг теж болючіший: коли червоніє крок «він входить у систему», причину доводиться діставати крізь кілька шарів замість того, щоб прочитати її одразу в тілі тесту. Звичайний Playwright-тест починається одразу з рівня step-логіки, тобто має на шар менше. Це не робить Gherkin поганим, але означає, що за нього треба платити, і платити варто лише коли є за що.

За яких умов Gherkin виправдовує свою ціну?

Головна умова одна — є реальний нетехнічний читач: продакт, аналітик, комплаєнс чи замовник справді відкривають сценарії або беруть участь у їх написанні. Друга — розмова відбувається насправді: команда практикує «три амігос» чи example mapping, і сценарії є підсумком спільного обговорення, а не витвором AQA поодинці. Третя — формат Given–When–Then закріплений у критеріях готовності історії як спільний контракт, а не осідає лише в тестовому репозиторії. Коли ці умови виконані, англомовний шар над тестами перетворюється на живий міст між бізнесом і кодом. Якщо жодна не виконується — ви несете витрати без вигоди.

Коли Gherkin стає чистим податком і як це розпізнати?

Коли інженерна команда автоматизації складає сценарії винятково для власного вжитку, а жоден колега без технічного бекграунду до них не зазирає, — надбудова над Playwright лише плодить роботу. У такому разі звичайний test('користувач входить у систему') з осмисленою назвою сам собою документує поведінку, і платити за парсинг та glue-код немає за що. Другий симптом податку — імперативні сценарії: до крихкості UI-тестів ви додали накладні витрати BDD, а читабельності натомість не здобули. Проста перевірка: подумки приберіть Gherkin — якщо цього не помітить ніхто, крім самих автоматизаторів, шар зайвий. Зрілий кандидат на співбесіді чесно назве цей випадок, а незрілий вважає BDD добром на всі випадки життя.

Що таке living documentation і за яких умов вона перестає працювати?

Термін є в офіційній доці Cucumber, але подано його там у лапках і без окремого означення: «Declarative scenarios read better as "living documentation"». Сам механізм дока формулює в іншому місці, у переліку трьох складових BDD: «Producing system documentation that is automatically checked against the system's behaviour». Звідси й ідея: той самий сценарій є одночасно й описом поведінки, й виконуваним тестом — змінилася система без відповідної правки сценарію, тест червоніє, і невідповідність одразу стає видимою в . Через це документація не старіє тихцем, як Confluence-сторінка, до якої не торкалися два релізи. Але «живість» тримається на трьох стовпах — і це вже наш перелік, не цитата доки, — кожен із яких нескладно вибити: сценарії мусять лишатися декларативними й читабельними, їх має хтось справді відкривати, а — світитися зеленим. Коли третина сценаріїв висить у @skip чи хронічно падає, набір документує вже не продукт, а те, що команда махнула на нього рукою. Тому не падає з неба разом із Gherkin — вона тримається на дисципліні, і про це чесніше говорити прямо.

Чому флакі-тест у BDD-обгортці шкідливіший за звичайний?

(flaky) — той, що падає й проходить на однакових умовах без змін коду — у BDD шкодить подвійно. По-перше, він робить те саме, що й будь-де: ламає гейт, змушує ретраїти білд, підриває довіру до сюїти. По-друге — і це вже специфіка BDD — він руйнує довіру до сценарію, що мав слугувати джерелом істини. Якщо сценарій-документація то червоний, то зелений без причини, читач перестає вірити не лише тесту, а й самому опису поведінки. Тобто в BDD б'є не тільки по інженерії, а й по головній обіцянці — живій документації. Тому в BDD-проєкті боротьба з важить ще більше, ніж у звичайній сюїті.

Що не так зі «сценарієм-простирадлом» і надто узагальненими кроками?

«Сценарій-простирадло» — це коли в один сценарій ліплять десяток When підряд, намагаючись «заощадити». Виглядає як економія, а насправді перевіряє одразу все й через те по суті нічого: причин для падіння в нього десяток, атомарність зламана, і з червоного прогону не видно, що саме відмовило. Інший бік тієї ж хвороби — надміру універсальні кроки-«швейцарський ніж» типу «When я тисну на "X"», з яких можна зібрати геть будь-що. Це не доменний словник, а той самий imperative, який пробрався з чорного ходу: під виглядом кроку ви знову описуєте кліки, лише винесли їх у параметр. Здоровий орієнтир — один сценарій на один бізнес-намір і кроки, що говорять термінами домену, а не елементами інтерфейсу.

Як би ти пояснив на співбесіді, коли НЕ радиш впроваджувати BDD?

Я б почав з того, що BDD — не універсальне добро, а інструмент з конкретною умовою окупності: реальний нетехнічний читач і жива практика розмов. Якщо команда суто технічна, пише тести сама для себе й ніхто ззовні їх не відкриває, Gherkin додає glue-код, ускладнює дебаг і нічого не дає натомість — тут describe/it з осмисленими назвами дешевше й чесніше. Так само я б застеріг від «BDD постфактум», коли Cucumber купили, а розмови «трьох амігос» немає: це просто дорожчий спосіб писати ті самі тести. Здатність назвати межу застосовності — саме те, що інтерв'юер хоче почути, бо вона відрізняє людину з досвідом від того, хто вивчив синтаксис. Догма «declarative завжди» чи «BDD усюди» — червоний прапор незрілості.

Три кейси, у яких видно межу між обіцянкою BDD і реальністю: переписування крихкого на декларативний зі step-кодом, «чи потрібен вам Gherkin взагалі», і міні-розбір історії через — де сам процес ловить діру у вимогах раніше за будь-який тест.

Кейс 1. Один сценарій, два світи: imperative → declarative

Прийшла історія «користувач логіниться». Перший AQA написав сценарій «як бачить», тобто через кроки інтерфейсу:

Feature: Автентифікація

  Scenario: Логін (імперативно)
    Given користувач на сторінці "/login"
    When він вводить "user@test.io" у поле "email"
    And вводить "Qwerty123" у поле "password"
    And натискає кнопку "Увійти"
    Then він бачить заголовок "Мій профіль"

Читається це не як вимога, а як інструкція до кліків. Тепер уявіть, що дизайнер перейменував поле email на login і замінив кнопку на іконку. Падає сам текст сценарію — той, що нібито мав читати продакт. Виходить найгірше з двох світів: крихкість UI-тесту плюс англомовний шар, який нікому не допомагає. По суті цей feature-файл дублює , тільки в прозі.

Той самий намір декларативно:

Feature: Автентифікація

  Scenario: Логін (декларативно)
    Given зареєстрований користувач
    When він входить у систему
    Then він потрапляє у свій профіль

Механіка кліків нікуди не зникла — вона переїхала на рівень нижче, у (step definitions), де їй і місце. Приклад на CodeceptJS:

import { Given, When, Then } from 'codeceptjs';

Given('зареєстрований користувач', async () => {
  // стан готуємо через API, а не кліками — швидко й стабільно
  const user = await api.createUser({ email: unique('user'), password: 'Qwerty123' });
  currentUser = user;
});

When('він входить у систему', async ({ I }) => {
  // уся крихкість локаторів схована тут; сценарій про неї не знає
  I.amOnPage('/login');
  I.fillField('email', currentUser.email);
  I.fillField('password', currentUser.password);
  I.click('Увійти');
});

Then('він потрапляє у свій профіль', ({ I }) => {
  I.see('Мій профіль');
});

Що змінилося і чому це важливо:

Перейменування поля тепер зачіпає лише крок When, а не сценарій. Текст, який читає бізнес, переживає редизайн форми — правиться тільки код.
Сценарій читається як вимога. «Користувач входить у систему» зрозуміло продакту; «вводить у поле email» — ні.
Given готує стан через API, а не через UI. Це та сама дисципліна, що й Arrange у звичайному тесті: створюємо найдешевшим шляхом, а перевіряємо — саме поведінку.
Балансу теж треба тримати. Якби Then звучав «Then усе добре», сценарій став би красивим і безкорисним. «Потрапляє у профіль» — конкретний, але не покроковий результат.

Кейс 2. Таблиця рішень: Gherkin окупається чи це податок?

Найчастіша помилка — впроваджувати Gherkin за замовчуванням, «бо BDD це добре». Насправді рішення зводиться до кількох чесних питань про вашу конкретну команду. Ось орієнтир замість здогадок:

Ситуація	Нетехнічний читач справді читає сценарії?	Є розмова (три амігос / example mapping)?	Вердикт
Продакт бере участь у написанні критеріїв, комплаєнс переглядає сценарії	Так	Так	Gherkin окупається — є за що платити
AQA-команда пише сценарії сама, показує їх лише собі	Ні	Ні	Податок: `describe/it` з гарними назвами дешевше
Cucumber купили «щоб було по-BDD», сценарії пишуть постфактум	Ні	Ні	Податок + ілюзія практики; це не BDD
Критерії приймання у форматі GWT в Jira, автотести окремо звичайні	Так (у тікеті)	Частково	GWT як контракт — так; окремий Gherkin-рушій — не обовʼязково

Як цим користуватися:

Ключова колонка — читач. Якщо жоден нетехнічний колега ніколи не відкриє feature-файл, англомовний шар над Playwright не додає нічого, крім роботи. Це головна умова, не «модно/немодно».
Розмова без інструмента цінніша за інструмент без розмови. Рядок 3 — класична пастка: заплатили повну ціну Cucumber, а вирівняного розуміння не отримали, бо обговорення не було.
GWT можна відірвати від рушія. Рядок 4 показує компроміс: формулювати через Given–When–Then корисно навіть тоді, коли самі тести лишаються звичайними. Мова існує окремо від Cucumber.
Проста фінальна перевірка. Подумки приберіть Gherkin зі свого проєкту. Якщо цього не помітить ніхто, крім самих автоматизаторів, — шар зайвий.

Кейс 3. Example mapping: як розмова ловить баг раніше за тест

Історія в беклозі звучить оптимістично: «Користувач може повернути замовлення й отримати гроші назад». Виглядає зрозуміло — доки команда не за example mapping і не починає виписувати правила з прикладами. Кольори карток нижче — не наша вигадка: офіційна дока Cucumber задає саме їх (історія жовта, правила сині, приклади зелені, питання червоні).

Rules (правила):

Повернення доступне протягом 14 днів після доставки.
Гроші повертаються тим самим способом, яким платили.

Examples (приклади під правила):

Доставлено 10 днів тому, оплата карткою → повернення дозволене, гроші на картку.
Доставлено 20 днів тому → повернення заборонене, показуємо причину.

Questions (стос запитань — те, чого ніхто не знає):

А якщо товар оплатили бонусами, які вже згоріли, — куди повертати гроші?
14 днів рахуються від доставки чи від оформлення?
Що з частковим поверненням, коли в замовленні кілька товарів?

Ось у чому суть кейсу: третє питання про бонуси не має відповіді ні в тікеті, ні в голові продакта — його виявили не тести, а сама розмова. Якби команда стартувала одразу з написання Gherkin постфактум, ця діра поїхала б у код, і її знайшли б у продакшені, а не за столом переговорів.

Коли на питання є відповіді, приклади перетворюються на сценарії — і природно декларативні, бо народилися з мови домену, а не з кліків:

Feature: Повернення замовлення

  Scenario: Повернення в межах вікна повертає гроші тим самим способом
    Given замовлення оплачене карткою й доставлене 10 днів тому
    When користувач оформлює повернення
    Then повернення підтверджене
    And гроші повертаються на картку

  Scenario Outline: Доступність повернення залежить від строку
    Given замовлення доставлене "<днів>" днів тому
    When користувач відкриває форму повернення
    Then система показує "<результат>"

    Examples:
      | днів | результат              |
      | 10   | повернення доступне    |
      | 20   | строк повернення минув |

Що тут працює на нас:

Стос питань окупив зустріч сам собою. Навіть якщо частину прикладів не встигли розписати, команда вже знає, чого не знає, — і це найдешевша точка виправити вимогу.
Сценарії вийшли декларативними без спеціальних зусиль. Вони говорять термінами домену («оформлює повернення»), бо джерело — розмова про поведінку, а не запис кліків.
Scenario Outline прибрав дублювання. Два майже однакові сценарії з різним строком стали одним параметризованим — це та сама ідея, що й data-driven тест.
Без кроку example mapping усе це не спрацювало б. Feature-файл — лише запис домовленості; якби домовленості (і питання про бонуси) не було, гарний Gherkin просто акуратно зафіксував би неповну вимогу.

BDD як практика, а не інструмент

Можу пояснити, що BDD — це співпраця навколо прикладів поведінки (Gherkin/Cucumber — лише спосіб її зафіксувати), і чому «пишемо тести на Gherkin» — слабка відповідь.
Розумію, що головна цінність народжується в розмові, а feature-файл — її побічний артефакт.
Знаю, звідки виросло BDD (з TDD, Ден Норт) і навіщо прибирали слово «тест».

Розмова: три амігос і example mapping

Можу назвати три ролі в «трьох амігос» так, як їх розписує офіційна дока Cucumber (product owner — , тестувальник — сценарії й граничні випадки, розробник — кроки й механіку), і знаю, що число «три» та одноразовість зустрічі дока прямо не вважає обмеженням.
Знаю, як влаштований (story → rules → examples → questions) і що робиться він до взяття історії в розробку; розумію, що теза «стос питань окупає зустріч» — наш висновок, а не твердження доки.

Анатомія сценарію: Given–When–Then

Знаю призначення Given (контекст), When (одна дія), Then (спостережуваний результат).
Можу показати відповідність GWT ↔ Arrange–Act–Assert і вивести з неї правило рев'ю: без у Given, без дій у Then.
Розумію, для чого Background (спільна ) і Scenario Outline з Examples (параметризація, data-driven), і знаю різницю між Gherkin (мова) і Cucumber (інструмент виконання) — GWT можна писати як без будь-якого інструмента.

Imperative проти declarative

Можу навести один і той самий сценарій імперативно й декларативно та пояснити різницю.
Знаю, чому крихкий і нечитабельний для бізнесу (дублює у прозі), а декларативний стабільніший: зміна UI зачіпає лише step definition. Пам'ятаю, що дока Cucumber імперативний стиль не засуджує — «in some contexts this style of test is appropriate».
Можу пояснити пастку «занадто декларативно» («все працює / все добре» нічого не перевіряє) і знаю, що це наше застереження: дока Cucumber попереджає про протилежний надмір — забагато деталей реалізації.

Ціна Gherkin: коли окупається, коли податок

Знаю, які накладні витрати додає Gherkin: , glue-код, важчий дебаг через кілька рівнів.
Можу назвати три умови окупності: реальний нетехнічний читач, жива практика розмов, GWT у критеріях готовності.
Розумію тест «прибери Gherkin — чи хтось поза командою автоматизації помітить?» і можу чесно назвати випадок, коли НЕ раджу BDD (технічна команда пише для себе).

Living documentation

Розумію, чому «жива» документація не може тихо застаріти (розбіжність = червоний ), і знаю формулювання доки: документація, що автоматично перевіряється проти поведінки системи.
Знаю три умови її «живості» — декларативність, реальний читач, зелена — і що це наш перелік, а не цитата доки (термін «living documentation» вона подає в лапках, без означення).
Можу пояснити, чому у BDD шкодить подвійно — ламає гейт і підриває довіру до документа.

Типові пастки

Розпізнаю «BDD постфактум»: Cucumber купили, розмови немає — це дорожчі ті самі тести.
Розпізнаю «сценарій-простирадло» з десятком When і розумію, чому він порушує атомарність.
Розпізнаю кроки-«швейцарський ніж» («When я натискаю X») як прихований imperative через чорний хід.

Знайшли помилку?

BDD і Gherkin: обіцянки і реальність

BDD — це практика співпраці, а не синтаксис

Given–When–Then: анатомія сценарію

Imperative проти declarative

Коли Gherkin виправданий, а коли це податок

Living documentation: коли документація справді жива

Типові помилки

Підсумок

Можливі питання

Джерела

Що таке BDD і чому неправильно зводити його до Gherkin?

Звідки взялося BDD і яку проблему TDD воно намагалося розвʼязати?

Що таке «три амігос» і навіщо цей ритуал?

Що таке example mapping і чим корисний його «стос питань»?

Як Given–When–Then співвідноситься з Arrange–Act–Assert?

Для чого потрібні Background і Scenario Outline?

У чому різниця між Gherkin і Cucumber?

Чим імперативний сценарій відрізняється від декларативного і що краще?

Чи буває сценарій «занадто декларативним»?

Які технічні накладні витрати додає Gherkin порівняно зі звичайним тестом?

За яких умов Gherkin виправдовує свою ціну?

Коли Gherkin стає чистим податком і як це розпізнати?

Що таке living documentation і за яких умов вона перестає працювати?

Чому флакі-тест у BDD-обгортці шкідливіший за звичайний?

Що не так зі «сценарієм-простирадлом» і надто узагальненими кроками?

Як би ти пояснив на співбесіді, коли НЕ радиш впроваджувати BDD?

Кейс 1. Один сценарій, два світи: imperative → declarative

Кейс 2. Таблиця рішень: Gherkin окупається чи це податок?

Кейс 3. Example mapping: як розмова ловить баг раніше за тест

BDD як практика, а не інструмент

Розмова: три амігос і example mapping

Анатомія сценарію: Given–When–Then

Imperative проти declarative

Ціна Gherkin: коли окупається, коли податок

Living documentation

Типові пастки

Пояснення

Свій API-ключ (BYOK)