BDD without the Cucumber overhead. Given/When/Then — straight in code.
I'm Dmitry, a QA Automation Engineer. I got tired of watching teams spend more time maintaining .feature files than actually testing their product — so I designed a simpler approach.
BDR keeps everything that's good about BDD (Given/When/Then, business-readable scenarios, living documentation) and removes the part that slows you down (Cucumber, Gherkin, step definition hunting).
I'm currently open to QA Automation roles — remote, contract, or full-time.
Telegram: @DmitryMeAQA
BDR transforms test automation from a "maintenance burden" into the Single Source of Truth about the product.
BDR values:
- Living Requirements over Stale Documentation.
- Behavioral Code over Tool-Specific Scripts.
- Infinite Reproducibility over Infinite Retries.
- Business Transparency over Technical Black Boxes.
That is, while there is value in the items on the right, I value the items on the left more.
- Write tests in Business Language. The Scenario Layer must read like a User Story.
- Invest in Reporting. The report is not just a log; it is a legal document of feature delivery.
- Separate Concerns. Technical details (selectors, API calls) live in a separate layer from Business Logic.
- Strive for Zero Frustration. Every failure must immediately answer "What?", "Where?", and "Why?".
- Write tests "for the tool". If I switch from Playwright to Selenium, the Specification Layer should not change.
- Ignore "Noise". Flakiness is a violation of "Infinite Reproducibility".
- Hoard "Secret Knowledge". Results must be accessible to Managers, Analysts, and Designers — not just engineers.
Cucumber is a great idea wrapped in a painful implementation. The moment your team grows, you start paying the Gherkin tax:
- A developer renames a button → 30 step definitions break
- Business writes a scenario → engineer spends an hour wiring it up
- Test fails → you hunt across
.featurefiles to understand what happened
BDR gives you the same Given/When/Then structure, the same readable scenarios, the same living documentation — but written directly in TypeScript (or your language of choice). Your IDE understands it. Refactoring works. Reports are rich.
- 4-Layer Architecture: The structural standard for BDR projects.
- Universal Pseudo-code: Framework-agnostic language for BDR specifications.
- Workflow: From Jira Ticket to BDR Spec.
- Ecosystem Mapping: How BDR maps to different languages and frameworks.
- Anti-Flakiness Guide: Strategies for stability.
- Scaling Patterns: How to handle growing test suites.
- Folder Structure: Project organization conventions.
- Data Management: Test data strategies.
- Diagnostic Integrity: Rich debugging in reports.
- Migration Guide: How to port legacy projects.
- Team Roles: Responsibilities in BDR adoption.
- FAQ: Frequently asked questions.
| Language | Framework | Repository | Status |
|---|---|---|---|
| TypeScript | Playwright | playwright-bdr-template | Official |
Contributions for other languages are warmly welcomed! See CONTRIBUTING.md.
BDR is an open standard. Contributions welcome:
- New implementations (Java, C#, Python, Go)
- Translations of the Manifesto
- Case studies of BDR adoption
See CONTRIBUTING.md for details.