Reference implementation

TypeScript Playwright

The TypeScript twin of the Python reference implementation: the same platform scope and phased engineering approach, rebuilt natively in TypeScript. Playwright is at home here — the test runner, fixtures, and failure artifacts are all first-party. The UI testing layer is shipped and verified; the REST API and MongoDB layers follow the same plan the Python twin completed.

View the source on GitHub

Where It Stands

Built in deliberate parity with the Python twin, phase by phase. Decisions made in one implementation are mirrored — or deliberately diverged with the reason recorded — in the other.

Delivery phases and their status
Phase	Capability	Status
0	Quality-gated TypeScript project: strict tsc, ESLint + Prettier, Vitest with a 90% coverage gate, pnpm audit	Shipped
1	React UI testing: page objects, host-aware browser matrix, dockerized sample app, Allure reporting, Linux + Windows CI	Shipped
2	REST API testing: typed fetch client, Zod-validated responses	In progress
3	MongoDB state verification and the full-stack scenario, plus the tester guide	Planned

First Run

Five commands from clone to a browsable test report. Node 24 LTS, pnpm, Docker Desktop, and GNU Make are the prerequisites; on native Windows the same pnpm scripts run without Make.

First run

make install            # dependencies (pnpm)
make install-browsers   # host-aware browser install, writes config/browsers.json
make docker-up          # start the dockerized sample React app
make test               # unit tests with coverage, then e2e across available browsers
make report             # Allure HTML report (pure-JavaScript Allure 3 CLI)

The browser matrix works exactly as in the Python twin: detection writes config/browsers.json, and the Playwright configuration derives its projects from the browsers marked available — including branded Chrome and Edge via channels. A launch smoke test proves every "available" browser genuinely runs.

The UI Layer

Page objects with React-suited locator conventions, documented and unit tested.

Page objects extend BasePage (route-path navigation, readiness contract) and follow a documented locator hierarchy: role with accessible name first, then label, then test id — structural CSS and XPath are excluded by policy. The conventions are documented in docs/page-objects.md in the repository, and the sign-in page object in src/pages/ is the executable reference.

The platform's own modules are unit tested with Vitest behind a 90 percent coverage gate, while e2e specs in tests/e2e/ drive the dockerized sample application across the browser matrix — 16 tests (4 specs by 4 browsers) green in CI.