Behaviour-Driven Development
Підтверджує, що BDD починається з collaboration і discovery, а не з automation syntax.
Чому критикують BDD і Cucumber → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
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 — лише один формат такої комунікації.
Антипатерн: 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.
Безпечний рефакторинг і навігація
На прикладі повторюваних рядків показано `Refactor → Introduce Variable`: PyCharm створює змінну з виділеного виразу й може замінити всі його входження. У демонстрації на macOS використовується `⌘⌥V`; на Windows або Linux слід дивитися актуальне скорочення безпосередньо в меню IDE. Так само винесено повторювані значення `classical` і `BDD` у зрозуміло названі змінні. IDE підсвічує невикористаний код сірим, тому зайві параметри й імпорти можна швидко знаходити та видаляти. Окрема команда оптимізує імпорти після змін. Для навігації показано: - `⌘B` — перейти до оголошення або реалізації символу під курсором; - `⌘⌥←` і `⌘⌥→` — повернутися до попереднього місця редагування або перейти вперед; - перехід на початок чи кінець рядка замість ручного руху курсора. Головна звичка: спочатку шукати дію в контекстному меню й дивитися її назву та скорочення, а вже потім за потреби змінювати keymap.
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.