Python мануфактураJavaDesign Patterns для автоматизаторів

Терміни, нюанси та джерела

Термін · 9:30

Feature-coupled step definitions

Step definitions, організовані навколо окремих feature files замість shared domain language; Cucumber описує цей підхід як anti-pattern через duplication і explosion of steps.

Чому критикують BDD і Cucumber →

Python мануфактура · Сесії: AMA та PMP · 3:10–6:20

Чому досвід поганого коду теж корисний

Чистий код важко зрозуміти лише з правил. Спочатку інженер пише прямолінійне рішення, потім стикається з duplication, coupling і складним maintenance — і лише тоді бачить, яку конкретну проблему вирішує refactoring або design pattern. Patterns і code smells не застосовуються механічно: різні правила можуть тягнути рішення в протилежні боки. Потрібен контекст, щоб вирішити, коли достатньо простого API call, а коли справді потрібні controller, DTO, serialization та додаткові abstraction layers.

Який рівень програмування потрібен automation engineer →

Python мануфактура · Сесії: AMA та PMP · 9:30–15:25

Антипатерн: 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.

Чому критикують BDD і Cucumber →
Запитати в чаті про «duplication» →