Less duplicated code, more than a thousand scenarios
Before the refactoring, the project's automation comprised 64 test files, more than 800 individual tests, and over 31,000 lines covering tests, page objects, and test data. Each page had a separate suite, even though many pages shared grids, filters, sorting, pagination, detail views, status actions, and exports.
The author reports that the refactoring reduced the test count by approximately 80%, total test-layer code by approximately 79%, and page object code by approximately 70%. About 25 shared test definitions now generate more than a thousand page-specific scenarios. According to the account, eliminating repeated implementations did not remove the behaviors under test.
The team also estimated that adding tests for another page took approximately four hours instead of 18. That estimate was not measured in a controlled experiment; the code and test-count figures came from a before-and-after comparison within the project. These are single-project results, not general benchmarks. The author expects smaller gains where fewer pages share the same functionality.
Why separate page suites became costly
Adding a page previously meant recreating much of the same work: navigation, data preparation, column checks, and interaction scenarios. Reusing page objects did not eliminate duplication in the test definitions themselves.
Changes to shared interface components then required edits across multiple suites. As those suites evolved independently, their coverage diverged: a page might retain outdated column checks or lack an export check present elsewhere. The problem was not simply repeated code, but the absence of a shared contract for what similar pages should verify.
The engine takes an explicit approach rather than using one generic test to discover controls at runtime. The author warns that runtime discovery can leave the runner making too many assumptions about the interface, producing brittle tests or weak assertions.
Specifications determine which tests exist
Each page has a structured specification containing its identity, capabilities, column metadata, navigation target, and setup requirements. It describes the page without spelling out a complete interaction sequence. Shared behavior suites supply that test logic.
A central registry collects the specifications. Readiness validation checks that each one includes the configuration required by its declared capabilities; incomplete entries do not proceed to execution. For example, a page configured to support details must also supply the setup needed to test them. The aim is to catch configuration problems before they appear as browser assertion failures.
The plan builder turns a validated specification into instructions for the shared suites, identifying applicable actions and organizing columns by data type. A page with details and exports but no status workflow receives the first two groups of tests, not the third. This selection happens before browser interaction, rather than through inspection of whatever controls appear at runtime.
Shared UI components and steps handle common interactions. Run-selection configuration determines which pages participate, while the behavior suites consume the generated plans instead of maintaining separate page lists.
Building on Playwright's existing reuse tools
The engine adds scenario selection to reuse mechanisms already available in Playwright Test. Playwright's documentation describes fixtures that keep setup and teardown together, work across test files, initialize on demand, and can be composed with other fixtures.
Playwright also supports parameterization within tests and across projects; parameterized projects can execute the same tests with different options. Those tools reduce repeated setup and configuration, but do not themselves determine which scenarios belong to a particular page. The specification and plan builder supply that decision.
Execution and reporting remain with Playwright. The engine registers ordinary tests and supplies structured tags or labels for CI filtering and reporting, rather than creating a separate system for test verdicts.
What the shared tests verify
The behavior catalog checks grid headers against column metadata, filtering and sorting according to column type, and pagination. Optional checks cover detail views, editable fields, status workflows, file exports, and visibility rules that keep soft-deleted records or older record versions out of view. Each recurring behavior has one implementation, with page plans determining where it applies.
Requirements documents do not feed the runner directly. Engineers encode the agreed requirements in page specifications, keeping test selection explicit and deterministic. That also means a requirements change can require a manual specification update.
A familiar modeling trade-off
This is a lightweight, manually maintained form of model-based testing, in which a model of the system provides the basis for generating test cases. The approach belongs to an established discipline rather than introducing an entirely new testing category.
In their 2025 arXiv preprint on MBTModelGenerator, Garousi and colleagues trace model-based testing to the 1970s. They identify the work of designing and updating models by hand as an obstacle to adoption, particularly for web applications.
The project account describes the same maintenance risk: a coded specification can fall out of step with the product. It recommends making specification updates part of the definition of done for relevant feature changes.
Limits, maintenance, and proposed improvements
The savings require an initial investment in capability definitions, validation rules, column metadata, and shared components. Building the first page may take more effort than writing a standalone suite. Shared code also concentrates risk: one faulty locator or assertion can disrupt tests for many pages.
The engine is intended for a family of similar, grid-based pages, not arbitrary interfaces. Forcing a distinctive workflow into an expanding collection of flags can make the abstraction harder to maintain. Such workflows should retain dedicated Playwright suites, while domain-specific rules included in the engine still need explicit metadata and test cases.
Readiness checks introduce another visibility concern. Excluding an unfinished specification prevents partially configured tests from running, but can also make an incomplete registration easy to overlook unless its status is tracked separately.
The author lists several possible improvements: a report of incomplete registrations, column metadata generated from one authoritative source, stronger contract checks between UI plans and API capabilities, and clearer criteria for choosing between the engine and a standalone suite.
For teams trying the approach, the suggested starting point is one fully configured page, a small set of meaningful capabilities, and one shared behavior suite. Additional pages and behaviors can follow when they demonstrate a genuine fit for the same model.
