Behaviour-Driven Development
Підтверджує, що BDD починається з collaboration і discovery, а не з automation syntax.
Чому критикують BDD і Cucumber → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
BDD
Collaborative, iterative process із practices Discovery, Formulation та Automation; executable documentation є наслідком shared understanding, а не заміною discovery.
Чому критикують BDD і Cucumber →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 — лише один формат такої комунікації.
`given`, `when`, `then` і login request
RestAssured надає BDD-синтаксис `given`/`when`/`then`. У `given` окремо задаються `baseUri`, `basePath`, request parameters і інша підготовка; path радять зберігати без завершального slash, а slash додавати на початку endpoint path. Для login request email і password передаються як `formParam`, після чого виконується `POST`. Спочатку очікується status `200`, а response body має містити token.
Антипатерн: 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.
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.
API-мислення, MVC, AAA і data-driven tests
MVC стає корисним словником, коли engineer працює з API та backend contract: model представляє дані, controller/endpoint приймає дію, view або client відображає результат. У тестовому коді DTO може типізувати JSON-відповідь, але не повинен автоматично копіювати кожну внутрішню модель сервісу. Сценарій зручно структурувати як Arrange–Act–Assert: підготувати стан, виконати одну ключову дію, перевірити результат. Повторювані варіанти можна виразити data-driven test, якщо таблиця прикладів не приховує різні бізнес-правила. На співбесідах також можуть питати BDD/Gherkin; важливо пояснити, коли цей формат покращує спільне розуміння, а коли лише дублює код.
Де 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.
RestAssured request і media types
RestAssured дає BDD-style `given`/`when`/`then`. У request configuration задаються base URI/path, headers, query/form parameters, body і logging; HTTP method запускає виклик, а response validation перевіряє result. `Content-Type` описує request body, `Accept` — бажаний response format. `415 Unsupported Media Type` і інші `4xx` часто свідчать про помилку request contract, тому headers перевіряються явно.