Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Візьміть один existing E2E scenario і назвіть його реальних readers.
Перепишіть його technology-neutral Given/When/Then із observable outcome.
Якщо reader і discovery loop відсутні, порівняйте maintenance cost із direct automated test.
Один scenario, список readers і аргументоване рішення залишити або прибрати Cucumber layer.
Дає first-party warning про feature-coupled step definitions і duplication, центральні для критики уроку.
Чому критикують BDD і Cucumber → Першоджерело ↗Step definitions, організовані навколо окремих feature files замість shared domain language; Cucumber описує цей підхід як anti-pattern через duplication і explosion of steps.
Чому критикують BDD і Cucumber →Оцінюйте Cucumber не за наявністю .feature files, а за реальним спільним обговоренням behavior, наявністю людей, які читають examples, і feedback loop після automation.
Чому критикують BDD і Cucumber →Підтверджує, що BDD починається з collaboration і discovery, а не з automation syntax.
Чому критикують BDD і Cucumber → Першоджерело ↗Типовий невдалий варіант: 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.
Невеликий набір 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.