Design a maintainable API and browser automation framework.

Instruction: Draw component boundaries, fixture lifecycle and CI flow. Explain tradeoffs and how failures remain visible.

Context:

A fictional team has two automation engineers, 30 API checks and six critical browser journeys. It already uses TypeScript and Playwright; replacing the stack is outside scope. Developers own component tests. The API suite takes four minutes and the browser suite six minutes on one worker each. A shared one-minute build/setup step must finish first. Three workers are available; all required PR checks must finish within ten minutes under these measured fixture timings. Setup includes independent namespaces and readiness checks. Chromium is required on PRs; Firefox/WebKit run nightly and before releases, and their results are part of the release gate.

Services run in an isolated test environment with authorized seed/cleanup APIs. The runner can inject short-lived test credentials and retain restricted failure artifacts. Tests currently share one user, repeat login in every journey and duplicate API assertions. Propose an incremental structure, not a new general-purpose platform.

Updated

Official answer available

Read the opening below, then unlock the full answer and practical guidance.

I would keep the runner and create small boundaries for data fixtures, API clients, page interactions and assertions. API tests would exercise real test-environment services. UI tests could use the API for setup while still exercising the browser behavior they claim to cover...

Related Questions