Skip to content

BDR Ecosystem Mapping

BDR is an architectural standard. This table shows how its core concepts map to popular tools and frameworks in different ecosystems.

BDR ConceptPlaywright (TS)Pytest (Python)JUnit/TestNG (Java)Go (Testing)
Layer 3 (Scenario)test('name', ...) (or equivalent)def test_name():@Testfunc TestName(t *testing.T)
Layer 2 (Domain)Classes in domain/Classes/ModulesDomain ClassesStructs / Receivers
Layer 1 (Flow)Classes in flows/Classes/ModulesActions/PagesLogic Packages
Layer 0 (Tech)Page, APIRequestPlaywright-pythonSelenium, RestAssuredPlaywright-go, net/http
Steps (Reporting)test.step()@allure.step@Step (Allure)allure.Step
Setup/TeardownFixturesFixtures@Before / @Aftert.Cleanup()
Assertionsexpect()assertassertThat()testify/assert

The goal of BDR is to keep the Domain and Specification layers as similar as possible across all stacks. The Technical layer is the only one where you use tool-specific APIs.

Regardless of the language, BDR requires that every Layer 2 action and Layer 1 flow is wrapped in a reportable step:

  • TS (Playwright): await test.step("Description", ...)
  • Python (Pytest): @allure.step("Description")
  • Java (JUnit): @Step("Description")
  • Go (Allure-Go): allure.Step(allure.NewStep("Description", ...))

This ensures that the final Living Documentation looks identical regardless of the underlying technology.