Skip to main content

Who does what

PACE E2E is designed so that testers, developers, and the AI each own a clearly defined slice of the work. Understanding those boundaries saves confusion about what you are expected to change — and what you should leave alone.

Testers (the no-code lane)​

As a tester, you own the intent of every test. Your jobs are:

  • Describe flows in English. Write a short description of what a user should be able to do and hand it to the Planner agent. Or record yourself clicking through the flow in the PACE app and hand the recording to the Stabilizer.

  • Edit test data. When a project ID changes, an estimate name needs updating, or a new environment gets added, you change the relevant file in tests/data/*.jsonc. These files are plain text and do not require coding knowledge.

  • Run AI commands. Kick off the Planner, Generator, and Reviewer using the slash commands or prompts documented on this site. Review the Reviewer's verdict and decide whether to accept the generated test or ask for a revision.

  • Run the suite and read the report. Run pnpm test (or trigger the CI workflow) and open the HTML report to see which tests passed, which failed, and why.

One rule: do not hand-edit the generated .spec.ts files in tests/e2e/. Those files are owned by the Generator. If a test needs to change, update the spec in tests/specs/ and regenerate.

Developers​

Developers own the infrastructure that the whole system depends on:

  • Page objects and helpers. The classes in tests/page-objects/ and the utilities in tests/utils/ are maintained by developers. When the PACE UI changes in a way that breaks a selector or a shared helper, a developer updates those files.

  • Fixtures. The Playwright fixture setup in tests/fixtures/ is developer territory.

  • The agents and the rulebook. The prompt files in tests/agents/ and the rulebook at tests/agents/rules/playwright-rules.md are maintained by developers. If a new project-wide test convention is adopted, it goes in the rulebook and the Generator will follow it from that point on.

  • CI. The GitHub Actions workflows, Docker images, and environment configuration are owned by developers.

  • Anything the AI can't handle. If the Reviewer repeatedly fails a test for a reason that requires a structural fix to the page objects or test infrastructure, that is a developer task.

The AI​

The AI agents sit between the tester's English description and the runnable test file. Their job is to:

  • Convert descriptions and recordings into a structured spec (Planner / Stabilizer)
  • Convert specs into correctly formatted, rule-compliant TypeScript test code (Generator)
  • Check that generated code meets the rulebook before a human reviews it (Reviewer)

The AI does not decide what to test — that is the tester's job. It does not decide how the page objects are built — that is the developer's job. It handles the repetitive, syntax-heavy work in between so that both testers and developers can focus on what they do best.

Next steps: