test-authoring

name	test-authoring
description	Create or improve unit tests and Playwright E2E tests for newly implemented features, and close coverage gaps based on project requirements. Use when the user asks to write/add/complete unit tests, add E2E tests, increase test coverage, or improve existing tests.

Test Authoring

Write tests for newly implemented functionality, or improve an existing project's test suite by using coverage data to identify gaps.

This skill is designed to work with projects generated by project-bootstrap (typical layout: core/, portal/, docker/, scripts/, docs/qa/, docs/ticket/), but should degrade gracefully on other layouts.

Decide Scope

Confirm which of these the user wants:

• Unit tests (backend and/or frontend)
• E2E tests (usually Playwright)
• Coverage improvement (and any target: e.g. "80%+ service layer")

If the user says "new feature implemented", treat the changed code as the test target (optimize for verifying behavior, not lines).

Discover Project Test Tooling

From repo root, identify:

• Backend language:
  • Rust: core/Cargo.toml exists
  • Other: ask for the test command and coverage command
• Frontend:
  • portal/package.json exists (TypeScript/React portal typical)
• E2E:
  • Look for Playwright: playwright.config.*, @playwright/test in package.json

Prefer running existing scripts in package.json / Makefile over inventing new ones.

Unit Tests (Backend)

Rust (core/)

Principles:

• Keep tests fast and deterministic.
• Prefer unit tests for business logic without Docker.
• Mock boundaries (repositories, HTTP clients) using traits and mock libraries (e.g. mockall).

Placement:

• For pure logic: colocate tests in core/src/** using #[cfg(test)] mod tests.
• For API/behavior tests: use core/tests/** if the project has a test harness there.

Workflow:

1. Identify behavior added/changed (inputs, outputs, error cases).
2. Add tests for:
   • Happy path
   • Boundary conditions
   • Negative cases (validation, authz, not-found, conflict)
3. Run backend tests (project-specific):
   • cd core && cargo test

Coverage (if requested):

• Prefer cargo llvm-cov if configured, otherwise follow the project's existing coverage commands.
• If no coverage tooling exists, propose adding cargo llvm-cov support (do not force-install tools without user confirmation).

Unit Tests (Frontend)

If portal/ exists, prefer:

• Unit tests for pure functions and data shaping.
• Component tests for complex rendering/interaction logic.
• Avoid brittle DOM selectors; prefer role/label based selectors in E2E (not unit).

Run commands (project-specific examples):

• cd portal && npm test
• cd portal && npx vitest --run
• Coverage: cd portal && npm test -- --coverage (or existing script)

E2E Tests (Playwright)

Goals:

• Cover critical user journeys with few, stable tests.
• Keep tests reproducible by resetting state when running full-stack.

Recommended split (if applicable):

• Frontend-only E2E: runs against dev server, minimal dependencies.
• Full-stack E2E: runs against Docker Compose services, uses ./scripts/reset-docker.sh before execution to avoid flaky state.

Workflow:

1. Determine target base URL(s) from the project (often http://localhost:<portal_port>).
2. Identify the minimal scenario that proves the feature works.
3. Implement Playwright tests using stable selectors:
   • Prefer getByRole, getByLabel, getByText.
4. For full-stack E2E, always reset first:

./scripts/reset-docker.sh
cd portal
npx playwright test

If the project already has scripts like test:e2e:full:reset, use them instead.

Coverage-Driven Improvement (Completing Unit/E2E Tests)

When asked to "complete tests" or "increase coverage":

1. Run the project's existing coverage command(s).
2. Identify the highest-value uncovered behavior:
   • Service/business logic over plumbing.
   • Branch coverage and error paths over getters/setters.
3. Add tests that assert behavior (not implementation details).
4. Re-run:
   • Unit tests
   • Coverage
   • E2E (if touched)

If the project has explicit coverage targets, follow them. Otherwise, treat coverage as a signal, not a goal.

Output Artifacts and Iteration Loop

If a change is tied to an approved plan:

• Generate QA docs via qa-doc-gen.
• Execute QA via qa-testing.
• If failures occur, create/fix tickets via ticket-fix.

Guardrails

• Do not add tests that require external network access.
• Avoid time-based flakiness; use explicit waits/conditions in E2E.
• Prefer deterministic seeds/resets for integration environments (./scripts/reset-docker.sh).