@antero/testing — starter scaffold

This is a deliberately small, runnable starting point for the exercise described in ASSESSMENT_BRIEF.md. It sketches the idea of a centralised testing package that projects import once (@antero/testing) and talk to over a stable API, so the tool underneath (Playwright today, maybe something else tomorrow) can be swapped without touching a single consumer test.

It is intentionally incomplete. The interesting decisions are left for you.

Run it

npm install
npm test         # runs the package tests + the example consumer test (all green via the mock driver)
npm run typecheck

No browser install required — a dependency-free MockDriver simulates a tiny app so the scaffold is green out of the box.

Layout

src/
  index.ts                  # THE public API. Consumers import from here and nowhere else.
  config.ts                 # picks which driver backs the e2e facade
  e2e/
    index.ts                # the Page facade — the stable surface tests are written against
    driver.ts               # the E2EDriver interface — the swap seam
    drivers/
      mock.driver.ts        # dependency-free in-memory driver (scaffolding, green by default)
      playwright.driver.ts  # TODO stub — the real extension point
    e2e.test.ts             # the package's own tests
examples/
  consumer-app/
    login.e2e.test.ts       # what a consuming project's test looks like (imports @antero/testing only)

Where the interesting decisions live

Search the code for DECISION POINT and TODO. Those comments mark the places we're most curious to hear your thinking on — the shape of the public API, whether the driver interface actually fits real tools, how a project selects a driver, and what should not be abstracted.

You are free to change anything here, including the structure and these choices themselves.