Test gen

test-gen

Translate "what needs to be verified" into "which kind of test + runnable code". Two jobs: decide unit vs e2e, and write tests that match the project's existing conventions.

One sentence behind every decision: unit tests guard the parts, e2e guards that the assembled whole actually works. Most frontend bugs are not "computed wrong" but "wired wrong" — data flows from an API through a store, through derived state, down to some component's class, and any broken assumption in that chain passes every unit test while the page breaks on click. e2e covers exactly that. This matters even more for AI-written code, whose understanding is local and which most easily produces "every part green, assembled it crashes".

Workflow

This skill expects parallel execution across multiple contexts. Detection, generation, and self-check are independent kinds of work — fan them out with subagents instead of doing everything serially. Each step notes what to parallelize.

Step 0 · Detect the project's test stack (parallelizable)

Never assume the stack. Launch read-only subagents in parallel to determine:

1. Component framework: Vue 3 / React / other (check package.json deps, file extensions).
2. Unit runner: Vitest / Jest (config files, scripts). Env: jsdom / happy-dom / node.
3. e2e runner: Playwright / Cypress (config, e2e/ or cypress/ dirs).
4. Network mocking: MSW present? a shared fixtures/mock package? Or per-test mocks?
5. Reusable assets: existing test helpers, fixtures, e2e/helpers.*, mount helpers, naming conventions, where tests live.

If the project has no test setup at all, tell the user to run /test-setup first, then come back.

Record the detected stack — every generated file must match it. The decision framework is universal; only the syntax of the generated code depends on the stack.

Step 1 · Parse input into verifiable units

Input may be a plain-language test case, a requirement, a component/function file, or a user flow. Break it into the smallest verifiable points — each answering "given this input/precondition, what observable result is expected".

Separate two kinds:

• Part-level: pure functions I/O, store actions/getters, composable/hook state transitions, a single component's render/events given props.
• Assembly-level: behavior crossing store → derived state → multiple components → API → render; failure/edge/retry/limit paths; streaming render, overlay enter/exit, real interaction timing.

Step 2 · Decide unit vs e2e

Classify each verifiable point with the framework below. If you cannot decide confidently, do not guess — go to Step 3 and ask. Read references/decision-framework.md for full rules, signals, and worked examples before concluding.

Quick reference:

Signal	Leans	Why
Pure logic, computation, data transform	Unit	A part; deterministic I/O; fastest, most stable
Store action/getter, composable/hook state	Unit	Call directly or mount in isolation
Single component render/events/branches given props	Unit	Isolated component test
A user "clicks through" flow across components/store/API	e2e	Assembled whole; catches the "wired wrong" units miss
Failure, timeout, retry, limit, stream interruption	e2e	Network-layer mock reproduces deterministically
Overlay enter/exit, streaming render, real interaction timing	e2e	Closest to a real user, hardest to fool
Heavy third-party DOM/canvas/rich-text integration	Consider excluding	Low cost/benefit to hard-test; exclude from coverage

Most features need both: parts covered by unit tests, key flows and failure paths locked by e2e. Tell the user how each point was classified and why.

Step 3 · Ask when unclear (use structured questions)

Whenever an uncertainty would affect test correctness, stop and ask rather than hallucinating an assertion. Typical cases:

• The real current behavior is unclear (assert current state vs ideal spec — see Principles).
• The API shape/fields/response is unknown and no fixture exists.
• The precondition to reach the target UI is unclear (auth, seeded data, a dev/debug entry).
• Failure/edge-path copy or UI is uncertain.
• Whether the feature is "not worth hard-testing / exclude from coverage" is unclear.

Offer concrete options with a recommendation. Record the resolution in the final report.

Step 4 · Generate test code in parallel (multiple contexts)

Once classified, fan out generation by independent artifact (use generalPurpose subagents), e.g.:

• Subagent A: unit tests for the module (in the project's unit-test location).
• Subagent B: e2e specs + any needed helpers.
• Subagent C: shared fixtures / mocks (all mock data lives in one shared source, reused by unit and e2e — never fork a second copy inside the app).

Each subagent's brief must include: the detected stack, the relevant references/conventions-*.md, the reusable assets found in Step 0, and the "assert current real behavior" principle. Follow references/conventions-unit.md, references/conventions-e2e.md, and references/mocking.md for syntax.

If artifacts depend on each other (e.g. an e2e spec needs a new fixture), produce fixtures first, then specs. Fan out everything independent in the same batch.

Step 5 · Self-check and run

Back in the main context:

1. Run the unit tests for the affected package.
2. Run the e2e tests (install browsers first if needed).
3. If red: first suspect an assertion locked to "ideal spec" instead of current behavior, or an unmocked request (strict mock modes fail loudly on purpose).
4. Lint the new files and fix issues.

Core principles (pass these to every subagent)

1. Assert "current real behavior", not "ideal product spec". A test's first job is regression protection — catching "I broke it by accident". If code reality differs from the product's intended spec, assert reality and add a comment: "if product changes to X, update here". Asserting the ideal spec makes the test red from day one; red-until-numb means a dead test.
2. Single source of mock data: fixtures live in one shared place, reused by unit and e2e. Change the API contract in one spot.
3. Unmocked requests should fail loudly (e.g. MSW onUnhandledRequest: 'error'; e2e intercept at the network layer). A silently-passing test that hit a real backend is worse than no test.
4. Write e2e in "human language": test names describe user-visible behavior; extract repeated steps into helpers.
5. Prioritize failure and edge paths — this is where e2e shines and manual testing can't give determinism.

Output report

## Test generation report

### Detected stack
- Framework / unit runner / e2e runner / mocking

### Breakdown & classification
| Verifiable point | Type | Target file | Reason |
|---|---|---|---|

### Files added/changed
- unit / e2e / fixtures

### Clarifications (if asked)
- Q / A

### How to run
- unit: ...
- e2e: ...

### Run result
- unit: X passed / e2e: X passed

### Reuse check
Checked <existing fixtures / helpers / tests>; reused ...; did not reuse because ...

Reference files

• references/decision-framework.md — Full unit-vs-e2e rules, signals, and worked examples. Read before concluding.
• references/conventions-unit.md — Unit/component test templates for Vitest & Jest (Vue & React).
• references/conventions-e2e.md — e2e templates for Playwright (and Cypress notes).
• references/mocking.md — The single-source-fixtures pattern: MSW (unit) + network interception (e2e) sharing one fixture set.