Gherkin
Domain-oriented language для concrete examples: Given задає known state, When — event, Then — observable outcome. Implementation details не повинні домінувати в scenario language.
Чому критикують BDD і Cucumber →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Three Amigos і справжня цінність Gherkin
BDD працює, коли product/business analyst, developer і tester разом розбирають examples, assumptions та edge cases до написання коду. У відео це описано як Three Amigos practice, до якої за потреби долучають інших ролей. `Given/When/Then` допомагає зафіксувати передумову, дію та очікувану behavior мовою, зрозумілою business і engineering. Цінність виникає під час розмови та static testing requirements, а не від самого факту, що текст збережено у `.feature` file.
Де Cucumber усе ж доречний
Невеликий набір Gherkin scenarios може бути корисним як зрозумілий business report: користувач може оформити замовлення, створити event, виконати payment або отримати потрібну analytics. Це має сенс, якщо stakeholders справді читають report і scenarios є спільним контрактом. Для детальної діагностики developers зазвичай потрібні не довгі Gherkin steps, а точні request data, `curl`, response, credentials для test environment, frontend/backend logs і stack trace. Тому практичний висновок відео: використовуйте BDD для спільного уточнення поведінки, а Cucumber — лише там, де його додаткова мова реально має читача й покриває невеликий набір стабільних business flows.
BDD у контексті способів розробки
Waterfall, Scrum, Kanban і Lean описують організацію delivery process. TDD, BDD і Domain-Driven Design деталізують, як команда формує implementation: через tests, observable behavior або domain model. Це різні площини, хоча в реальних процесах вони поєднуються. Початкова проблема однакова для різних індустрій: business має пояснити engineering team, який результат потрібен. Для цього використовуються user stories, diagrams, domain language і examples. Gherkin — лише один формат такої комунікації.
Business example не замінює engineering task
Після узгодження behavior загальний scenario треба декомпозувати. Frontend task описує component, validation і UI states; backend task — endpoint, contract і business rule; test task — ризики й потрібне coverage. Для інженера прямий технічний опис часто коротший і точніший за повторення кожної умови через `Given/When/Then`. Проблема починається, коли один формат примусово використовують для всіх ролей. Business не має керувати деталями automation code, а automation engineer не повинен перекладати вже зрозумілий technical contract у довший Gherkin лише для формальної відповідності процесу.
Антипатерн: Cucumber живе тільки в automation
Типовий невдалий варіант: manual test cases уже містять steps, але автоматизатор повторно перекладає їх у Gherkin, а потім створює step definitions. Одна дія існує як feature text, regex/parameterized step і code implementation. Різні автори формулюють однакові steps по-різному, тому повторне використання швидко руйнується. Management може вимагати кількість automated scenarios або «читабельний для business report», але потім не відкривати ці reports. У такій ситуації Cucumber не забезпечує BDD: він лише додає maintenance cost команді automation. Ознака справжнього BDD — scenarios використовуються для спільних рішень, а не лежать наприкінці pipeline.
Що насправді потрібно продукту
Business зазвичай цікавить, чи можна продемонструвати й продати ключовий flow, чи стабільний продукт і чи не блокують bugs інвестиції або клієнтів. Формат внутрішньої документації другорядний, доки він допомагає команді передбачувано delivery-ити результат. Додаткові process artifacts стають виправданими, коли зменшують реальну проблему: часті incidents, втрату domain knowledge, складний onboarding або неоднозначні requirements. Сам по собі Gherkin не виправляє низьку якість implementation чи відсутність coverage.