Ai Test Generation

<objective> LLMs will happily emit fifty plausible-looking tests that assert nothing, target endpoints that do not exist, and duplicate each other. This skill is a staged pipeline that forces structured intermediates — assumptions, coverage matrix, oracle definitions — out of the model BEFORE any test code, so what you get is traceable, reviewable, and grounded in the real codebase instead of ad-hoc generated noise.

Before starting: Check for .agents/qa-project-context.md in the project root. It carries tech stack, test frameworks, naming conventions, selector strategy, and known risk areas that dramatically improve generated test quality. </objective>

Quick Route

The pipeline is the same for every input; only the Step 1 extraction emphasis changes. Jump to the matching row, then run Steps 2-7 unchanged.

Playwright projects also pick an agent integration mode — see Discovery Q2.

Discovery Questions

Check .agents/qa-project-context.md first — if it exists, use it and skip anything already answered there. Then clarify:

1. What is the input source? PRD / spec, user story + AC, code diff, bug report, or API schema. Determines Step 1 extraction emphasis (see Quick Route). For an LLM/AI feature spec, stop — generate eval datasets in ai-system-testing, not Playwright specs.

2. What is the target test framework, and (for Playwright) which agent integration mode?

• E2E: Playwright (preferred), Cypress. Unit: Jest, Vitest, pytest. API: Playwright APIRequestContext, Supertest, requests.
• Playwright CLI + agents (recommended for Claude Code / Codex / Cursor): npx playwright init-agents --loop=claude scaffolds planner/generator/healer agents into .claude/agents/ as markdown. They are interactive dev tools that produce standard Playwright tests which run unchanged in CI. Token-efficient; runs inside the agent's loop.
• Playwright MCP (npx @playwright/mcp@latest): higher overhead, right when the agent must drive a live browser interactively over a long session.
• Neither — hand-write tests using AI as a scratch-pad helper.

3. What project context is available? Existing test patterns, Page Objects / helpers, data factories / fixtures, CI constraints (timeout, parallelism). More context = less cleanup.

4. What is the review workflow? Full pipeline → human review → merge (default); scenarios only → human writes code; or code → human refines iteratively.

5. What domain knowledge is needed? Regulated industry (healthcare, finance) compliance, domain invariants (money never negative, appointments cannot overlap), known risk areas from past incidents.

Core Principles

1. Pipeline before code. Never generate test code before establishing what to test, why, and how to verify it. The seven-step pipeline exists to prevent premature code generation that targets the wrong things.

2. Structured intermediates are the product. The assumptions document, coverage matrix, and oracle definitions are more valuable than the test code itself. They are reviewable, traceable, and reusable.

3. Separate what from how. Scenario generation (what to test) and oracle design (how to verify) are distinct cognitive tasks. Mixing them produces scenarios biased toward what is easy to assert, with assertions tacked on as afterthoughts.

4. AI generates the first draft; a human reviews and refines. Never ship AI-generated tests without human review. The AI accelerates — it does not replace judgment.

5. Context is everything. Feed the LLM your conventions, existing patterns, selector strategy, and data setup. The more context, the less cleanup.

6. Quality over quantity. Each test has a maintenance cost. Focus on critical paths, complex logic, and known risk areas — not test count.

The Pipeline

Mandatory workflow — agents MUST follow this order:

Step 1: Extract   → Requirements, entities, business rules from input
Step 2: Analyze   → Risks, invariants, edge cases, ambiguities
Step 3: Map       → Coverage matrix (requirement → scenario → priority)
Step 4: Generate  → Candidate scenarios (happy + boundary + negative + security + a11y)
Step 5: Design    → Assertions and oracles SEPARATELY from scenarios
Step 6: Code      → Test code (only after all above exist)
Step 7: Review    → Human review with traceability back to source

Full prompt templates for every step (extraction, risk analysis, scenario, oracle, code) live in references/prompt-patterns.md. Below is the shape of each step's output.

Step 1: Extract Requirements and Entities

Parse the input into structured elements: Entities (with roles/states/attributes), Business Rules (numbered), Explicit Requirements ([REQ-N], stated in source), and Implicit Requirements ([IMP-N], inferred — flag every one for human confirmation). Separating explicit from inferred is the rule that prevents testing assumptions as if they were specifications.

Step 2: Risk Analysis and Invariants

Derive what can go wrong, what must always be true, and where the source is silent.

• Risks — table of Risk | Likelihood | Impact | Source Requirement (e.g. race condition on stock decrement, email delay > 30s).
• Invariants (must ALWAYS hold) — stock >= 0, order total = sum(items) + tax + shipping, user sees only their own orders.
• Ambiguities (need human answers) — "Does free shipping apply before or after discount codes?" Capture these explicitly; do not silently pick one.
• Edge cases derived from risks — two users buy the last item, payment succeeds but email service is down.

Step 3: Coverage Matrix

The single most important artifact — it prevents both gaps and duplicates. Map every requirement to scenarios with category, priority, and oracle type:

After building it, verify: every requirement has ≥1 happy and ≥1 negative scenario; every invariant has a direct test; every Step-2 risk has a scenario; no two rows test the same thing.

Step 4: Generate Candidate Scenarios

For each matrix row, write the full scenario in Given/When/Then with explicit test-data requirements (Given: user with 99 items in cart (max 100); When: adds one more; Then: count = 100). Cover these categories systematically:

Step 5: Design Assertions and Oracles

Deliberately separate from Step 4. Scenarios describe behavior; oracles describe how to verify it. For each scenario, define oracles across categories — a single assertion is rarely enough to prove a behavior:

Oracle quality rules: assert business outcomes not implementation details; use the most specific assertion available (toHaveText('$29.99'), not toBeTruthy()); include negative assertions; verify data integrity, not just UI; assert accessibility (focus management, live-region announcements).

Step 6: Generate Test Code

Only after Steps 1-5 produce reviewed artifacts. Code is a mechanical translation of scenarios + oracles into framework syntax, with traceability comments linking back to the requirement and scenario:

/**
 * Scenario: SC-001 — Add single item to empty cart
 * Requirement: REQ-1 (User can add items to cart)
 * Priority: P0
 */
test('add single item to empty cart', async ({ page, testProduct }) => {
  await page.goto(`/products/${testProduct.id}`);                       // Given
  await page.getByRole('button', { name: 'Add to cart' }).click();      // When
  await expect(page.getByTestId('cart-badge')).toHaveText('1');         // Then
  await expect(page.getByTestId('error-toast')).not.toBeVisible();      // Negative oracle
});

Code generation rules: match project conventions (from qa-project-context.md); reuse existing Page Objects, fixtures, and data factories; include traceability comments (Scenario: SC-XXX, Requirement: REQ-XX); follow the project's selector strategy; put setup/teardown in fixtures, not inline.

Step 7: Human Review

Not optional — a mandatory pipeline step. This reviews the tests this pipeline just generated, before they merge. (To audit a pre-existing suite you did not just generate, use ai-qa-review instead.) Run every generated test against this checklist:

• [ ] Traces to requirement: test → scenario → coverage row → requirement is followable.
• [ ] Tests behavior, not implementation: survives a harmless refactor.
• [ ] Correct abstraction level: right test type (unit vs integration vs E2E).
• [ ] Test naming and readability: the test name states the behavior; a reader sees intent without decoding the body.
• [ ] Test isolation / no shared state: the test creates and cleans up its own data, holds no order dependency on sibling tests, and passes when run alone or in any order.
• [ ] Realistic test data: plausible, diverse, using example.com.
• [ ] Meaningful assertions: matches the oracle definition; specific, not toBeTruthy().
• [ ] Matches project conventions: naming, structure, selector strategy.
• [ ] No flakiness risks: no hardcoded timeouts, race conditions, or order dependence.
• [ ] Edge cases included: goes beyond the happy path.
• [ ] Assumptions validated: Step-2 ambiguities were resolved before coding.

Review outcome per test: KEEP (merge as-is) · MODIFY (fix listed issues, then merge) · REJECT (wrong requirement, wrong abstraction, hallucinated API) · DEFER (blocked on ambiguity).

Guardrails

Hard rules. Agents MUST follow them.

• Code before coverage is forbidden. Never emit test code before Steps 1-3 (requirements, risk analysis with documented assumptions, coverage matrix) exist. If an agent skips to code: STOP, go back.
• Assert outcomes, not implementation. expect(screen.getByRole('progressbar')).toBeVisible(), not expect(component.state.isLoading).toBe(true). expect(page.getByTestId('cart-badge')).toHaveText('1'), not expect(store.dispatch).toHaveBeenCalledWith(...).
• Scenarios (Step 4) before oracles (Step 5), always. Scenario = WHAT happens; oracle = HOW to verify. Mixing them biases scenarios toward easy assertions.
• Always produce the intermediates — assumptions document, uncovered ambiguities, oracle candidates, and the traceability chain — even in abbreviated form.

Flag these when detected:

• Hallucinated APIs — endpoints, selectors, methods, or imports that do not exist in the codebase. Verify mechanically (see Verification) before human review.
• Duplicate scenarios — same behavior, trivially different data. Consolidate or parametrize.
• Low-value assertions — expect(response).toBeTruthy(), expect(page).toHaveURL(/.*/).
• Missing negative cases — if every scenario is a happy path, the coverage matrix is incomplete.
• Unrealistic test data — test@test.com, John Doe, password123. Use diverse, plausible data on example.com.

Model selection per step

Route by difficulty, not habit. Use a cheap model for mechanical extraction (Step 1) and the coverage-matrix bookkeeping (Step 3) — Haiku 4.5 or Sonnet 4.6 are plenty. Escalate to Opus 4.8 for oracle design (Step 5) and hallucination-sensitive code generation (Step 6), where a wrong inference is expensive; reach for Fable 5 only on genuinely hard reasoning (subtle invariants, regulated-domain logic). Running the strongest model on every step is wasteful; running the cheapest on Step 6 produces fabricated APIs.

Verification

Convert the "hallucinated APIs" warning into a mechanical gate. After Step 6, before human review:

1. Resolve imports / types. TypeScript: npx tsc --noEmit — fabricated imports and wrong signatures fail here. Python: python -m pyflakes <files> or ruff check. 2. Grep generated selectors/endpoints against the codebase. Confirm every getByTestId('...') id and every API path the test calls actually exists in source:

   grep -roE "getByTestId\('([^']+)'\)" generated/ | sed -E "s/.*'([^']+)'.*/\1/" | sort -u \
     | while read id; do grep -rq "$id" src/ || echo "MISSING testid: $id"; done

3. Run the suite once. Tests that reference nonexistent routes/selectors fail fast; quarantine those before review rather than reviewing dead code.

Any MISSING line or tsc error is a hallucination to fix before a human spends review time.

Anti-Patterns

1. Skipping to code. The most common failure: an agent gets a PRD and immediately writes tests. Without the coverage matrix it misses scenarios and duplicates others. The pipeline exists to prevent this. 2. Asserting implementation instead of behavior. expect(component.state.isLoading).toBe(true) breaks on any refactor. Assert expect(screen.getByRole('progressbar')).toBeVisible() — what the user observes. 3. Mixing scenarios and assertions. Writing "test this thing and check this value" as one step. Separate what to test from how to verify it. 4. No project context in the prompt. Without conventions and existing patterns, you get generic tests. qa-project-context.md exists for exactly this. 5. Over-generating. AI will write 50 tests for a simple function. Each carries maintenance cost. Use the coverage matrix to bound generation to meaningful scenarios. 6. Copy-paste without understanding. If you cannot explain what a generated test does and why, do not merge it. Tests you do not understand become tests you cannot debug. 7. Shipping without review. Step 7 is not optional. AI tests routinely contain hallucinated APIs, wrong selectors, incorrect business logic, and flakiness only human review catches. 8. Ignoring the feedback loop. When AI tests catch real bugs, note the prompt patterns that worked; when they false-positive, note what went wrong. Build a project-specific library of what works.

Done When

• All seven artifacts exist: requirements document, risk & invariants, coverage matrix, scenario set, oracle definitions, test code, and review notes with a KEEP/MODIFY/REJECT/DEFER decision per test.
• The coverage matrix was produced and reviewed before any test code file was written.
• Verification passed: tsc --noEmit (or language equivalent) exits 0 and the selector/endpoint grep reports zero MISSING lines.
• Each generated test has a recorded human review decision; no test is marked KEEP without one.
• The suite's CI job exits 0 (green).
• Reproducibility metadata recorded: the exact model ID (e.g. claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5-20251001), input source hash, and the version of any skill / CLI / MCP server invoked.

Related Skills

• qa-project-context — Set up the context file that makes AI test generation dramatically better. Configure this first.
• playwright-automation — Deep Playwright patterns (POM, fixtures, CI), plus the Test Agents (init-agents --loop=claude, scaffolded into .claude/agents/) and @playwright/mcp modes chosen in Discovery Q2. Generated tests live inside this framework.
• unit-testing — Jest, Vitest, pytest patterns for unit-level generated tests.
• api-testing — Endpoint test patterns for tests generated from OpenAPI specs.
• test-strategy — Decide what to test and at which level before generating.
• test-reliability — Make generated tests reliable: flake classification, healing, video receipts.
• ai-system-testing — When the input is an LLM feature spec, generate eval datasets here (Promptfoo, DeepEval, Ragas, Braintrust) instead of Playwright specs.
• ai-qa-review — Audit a pre-existing suite you did not just generate (test smells, testability). Step 7 here only reviews this pipeline's own output.
• ai-bug-triage — When generated tests find bugs, classify and report them through the triage pipeline.

Reference Files (in references/)

• prompt-patterns.md — Full prompt library aligned to the seven steps: extraction, risk analysis, scenario generation, oracle design, and code generation prompts, plus the BOUNDARIES edge-case framework used in Step 4.

AI Test Generation — Prompt Library (Staged Pipeline)

Prompts aligned with the seven-step pipeline. Each prompt corresponds to a pipeline step. Use them in order. Replace bracketed placeholders with actual content.

---

Step 1: Requirements Extraction Prompt

System Prompt

You are a senior QA engineer extracting testable requirements from a specification.
Your job is to identify every entity, business rule, explicit requirement, and implicit
assumption. You must separate what is stated from what is inferred.

Output format:

## Entities
[List each entity with its attributes, states, and relationships]

## Business Rules
[Numbered list of rules governing entity behavior]

## Explicit Requirements
[REQ-N] [Requirement as stated in the source]

## Implicit Requirements (inferred — flag for human confirmation)
[IMP-N] [Inferred requirement] — Basis: [why you inferred this]

## Open Questions
[Questions that the source does not answer but testing requires]

User Prompt Template

Here is the [PRD / user story / API schema / code diff]:

---
[PASTE FULL SOURCE HERE]
---

Extract all testable requirements following the format above. Rules:
- Include every entity mentioned, even if only referenced indirectly
- Separate explicit requirements (directly stated) from implicit ones (inferred)
- For each implicit requirement, explain your reasoning
- List open questions that would affect test design
- Do NOT generate test scenarios yet — only extract requirements

---

Step 2: Risk Analysis Prompt

System Prompt

You are a QA risk analyst. Given a set of requirements and entities, identify:

1. Risks — what can go wrong, with likelihood and impact
2. Invariants — conditions that must ALWAYS be true regardless of input
3. Ambiguities — questions the spec does not answer that affect test design
4. Edge cases — derived from risks and boundary analysis

Use the BOUNDARIES framework for systematic edge case discovery:
B - Boundary values (min, max, zero, negative, overflow)
O - Ordering (sorted, reversed, duplicates, already-processed)
U - Unicode & encoding (emoji, RTL, special chars, multibyte)
N - Null/empty (null, undefined, empty string, whitespace-only)
D - Data volume (zero items, one, many, max capacity)
A - Access & permissions (no auth, expired, wrong role, own vs other's data)
R - Race conditions (concurrent writes, double-submit, stale reads)
I - Integration failures (timeout, 5xx, partial failure, malformed response)
E - Environment (timezone, locale, screen size, browser, OS)
S - State transitions (valid paths, invalid transitions, re-entry)

Output format:

## Risks
| Risk | Likelihood | Impact | Source |
[table rows]

## Invariants
[Numbered list of conditions that must always hold]

## Ambiguities
[Numbered list of unanswered questions]

## Edge Cases (BOUNDARIES)
| Category | Case | Input | Expected Behavior | Risk Level |
[table rows]

User Prompt Template

Here are the extracted requirements:

---
[PASTE STEP 1 OUTPUT HERE]
---

Analyze risks, invariants, and edge cases. Rules:
- Every business rule should have at least one associated risk
- Cover every letter of the BOUNDARIES framework
- Rank risks by likelihood × impact
- Flag ambiguities that block test design decisions
- Do NOT generate test scenarios yet — only analyze risks

---

Step 3: Coverage Matrix Prompt

System Prompt

You are a test planning engineer creating a coverage matrix. Given requirements, risks,
and invariants, map them into a structured matrix that ensures complete coverage with
no gaps and no duplicates.

Output format — a markdown table:

| ID | Requirement | Scenario Summary | Category | Priority | Oracle Type | Notes |
[table rows]

Categories: happy path, boundary, negative, security, accessibility, concurrency, state transition
Priority: P0 (blocks release), P1 (should fix before release), P2 (nice to have)
Oracle Type: UI state, data integrity, side effect, negative (absence), performance threshold

After the matrix, include:
## Coverage Analysis
- Requirements with no negative scenario: [list]
- Invariants with no direct test: [list]
- Risks with no corresponding scenario: [list]
- Potential duplicate scenarios: [list pairs]

User Prompt Template

Requirements (Step 1 output):
---
[PASTE STEP 1 OUTPUT]
---

Risk Analysis (Step 2 output):
---
[PASTE STEP 2 OUTPUT]
---

Create a coverage matrix. Rules:
- Every explicit requirement needs at least one happy path AND one negative scenario
- Every invariant needs a direct test
- Every high-risk item needs a scenario
- Flag potential duplicates
- Assign priorities based on risk analysis
- Do NOT generate detailed scenarios yet — only the matrix

---

Step 4: Scenario Generation Prompt

System Prompt

You are a senior QA engineer writing detailed test scenarios. Given a coverage matrix,
expand each row into a full Given/When/Then scenario with test data requirements.

Output format for each scenario:

## SC-[NNN]: [Descriptive title]
- **Requirement:** [REQ-ID or INV-ID]
- **Category:** [from coverage matrix]
- **Priority:** [P0/P1/P2]
- **Given:** [Preconditions — be specific about state, data, and user role]
- **When:** [User action or system event — single action per scenario]
- **Then:** [Expected outcome in business language — not assertions yet]
- **Test data:** [Specific data needed, how to create it]
- **Notes:** [Risks, related scenarios, implementation hints]

Rules:
- One action per scenario (the "When" clause has one verb)
- Preconditions must be achievable (no impossible states)
- Expected outcomes describe business behavior, not UI mechanics
- Test data requirements are specific enough to implement

User Prompt Template

Coverage matrix (Step 3 output):
---
[PASTE STEP 3 OUTPUT]
---

Project context:
- Framework: [Playwright / Jest / pytest]
- Data setup: [API seeding / fixtures / factories]
- Auth strategy: [How test users authenticate]

Generate full scenarios for every row in the matrix. Rules:
- Do NOT write assertions or test code yet — only scenarios
- Each scenario has exactly one "When" action
- Be specific about test data (not "some user" but "user with admin role and 3 orders")
- Flag scenarios that depend on other scenarios' state

---

Step 5: Oracle Design Prompt

System Prompt

You are a test oracle designer. Given test scenarios, define HOW to verify each one.
Separate verification into categories: UI state, data integrity, side effects, and
negative checks (things that should NOT happen).

Output format for each scenario:

## SC-[NNN]: [Title]

### UI State Oracles
[What should be visible/hidden/changed in the UI]

### Data Oracles
[API responses, database state, computed values to verify]

### Side Effect Oracles
[Emails sent, events fired, logs written, external calls made]

### Negative Oracles
[Things that must NOT happen — errors, state changes, navigation]

### Assertion Specificity
[For each oracle, the most specific assertion type to use]

Rules:
- Assert business outcomes, not implementation details
- Use the most specific assertion available (toHaveText > toContainText > toBeTruthy)
- Include at least one negative oracle per scenario
- Verify data integrity, not just UI state
- Note assertions that require waiting for async operations

User Prompt Template

Scenarios (Step 4 output):
---
[PASTE STEP 4 OUTPUT]
---

Framework: [Playwright / Jest / pytest]
Available selectors/test IDs: [List known data-testid values, ARIA patterns]
API endpoints available for verification: [List relevant APIs]

Design oracles for every scenario. Rules:
- Do NOT write test code yet — only oracle definitions
- Every scenario must have at least one positive and one negative oracle
- Prefer behavioral assertions over state inspection
- Note where you need to wait for async operations

---

Step 6: Code Generation Prompt

System Prompt

You are a test automation engineer translating scenarios and oracles into executable
test code. Every test must include traceability comments linking back to the scenario
and requirement it covers.

Rules:
- Include "Scenario: SC-NNN" and "Requirement: REQ-NN" comments in each test
- Use the project's existing Page Objects, fixtures, and factories
- Follow the project's naming conventions and file organization
- Generate setup and teardown via fixtures, not inline code
- Use the selector strategy defined in the project context
- Include both positive and negative assertions from oracle definitions
- Do NOT invent APIs, selectors, or helpers that do not exist in the codebase

User Prompt Template

Scenarios with oracles (Step 4 + Step 5 output):
---
[PASTE COMBINED OUTPUT]
---

Project context:
- Framework: [Playwright / Jest / pytest]
- Test file location: [e.g., e2e/tests/, __tests__/, tests/]
- Naming convention: [e.g., feature.spec.ts, test_feature.py]
- Page Objects: [list available POMs with their methods]
- Fixtures: [list available fixtures]
- Factories: [list available data factories]
- Selector strategy: [data-testid preferred, ARIA roles, etc.]

Generate test code for all scenarios. Rules:
- Each test includes traceability comments
- Use existing helpers — do NOT create new ones unless necessary
- Group related tests in describe/context blocks
- Include setup and teardown via fixtures
- Match the project's assertion style exactly

---

Step 7: Review Prompt

Use an LLM to review generated tests before human review.

System Prompt

You are a senior QA engineer reviewing AI-generated test code against its source
scenarios and oracles. Evaluate each test on these criteria:

1. **Traceability** — Does the test link back to a scenario and requirement?
2. **Behavioral focus** — Tests behavior, not implementation details?
3. **Correct abstraction** — Right test type (unit vs integration vs E2E)?
4. **Oracle completeness** — Does it include all oracles from the oracle definition?
5. **Data quality** — Realistic, diverse, using example.com for emails?
6. **Setup/teardown** — Self-contained, cleans up after itself?
7. **Flakiness risk** — Hardcoded timeouts, race conditions, order-dependent?
8. **Convention match** — Follows project patterns for naming, structure, selectors?
9. **Hallucination check** — All referenced APIs, selectors, and helpers actually exist?
10. **Negative coverage** — Includes negative assertions from oracle definitions?

Output format:

## Review Summary
- **Overall:** PASS | NEEDS WORK | REJECT
- **Tests reviewed:** [count]
- **Issues found:** [count by severity]

## Per-Test Review
[For each test: verdict (KEEP/MODIFY/REJECT) with specific issues]

## Hallucination Flags
[Any references to APIs, selectors, or methods that may not exist]

## Missing Coverage
[Scenarios from the matrix that have no corresponding test]

---

Supplementary Prompts

BOUNDARIES Edge Case Discovery

Given this feature: [FEATURE DESCRIPTION]

Use the BOUNDARIES framework to identify edge cases:
B - Boundary values (min, max, zero, negative, overflow)
O - Ordering (sorted, reversed, random, duplicates)
U - Unicode & encoding (emoji, RTL, special chars, multibyte, zero-width)
N - Null/empty (null, undefined, empty string, empty array, whitespace-only)
D - Data volume (zero items, one item, max capacity, beyond max)
A - Access & permissions (no auth, expired, wrong role, own vs other's data)
R - Race conditions (concurrent writes, double-submit, stale reads)
I - Integration failures (timeout, 5xx, partial failure, malformed response)
E - Environment (timezone, locale, screen size, browser, OS)
S - State transitions (valid paths, invalid transitions, re-entry)

For each edge case, provide:
- **Category:** [BOUNDARIES letter]
- **Case:** [one-line description]
- **Input:** [specific test input]
- **Expected:** [what should happen]
- **Risk:** low | medium | high

Sort by risk (high first).

Bug Reproduction Test

Bug report:
Title: [BUG TITLE]
Severity: [critical | major | minor]
Steps to reproduce: [NUMBERED STEPS]
Expected behavior: [WHAT SHOULD HAPPEN]
Actual behavior: [WHAT ACTUALLY HAPPENS]
Environment: [browser, OS, user role]

Framework: [Playwright / Jest / pytest]

Generate a failing reproduction test. The test MUST:
1. Assert the EXPECTED (correct) behavior so it fails now
2. Pass once the bug is fixed (serving as a regression test)
3. Include clear comments: expected vs actual, suspected root cause
4. Set up the exact conditions from the bug report
5. Be deterministic — no timing-dependent assertions

Test Data Generation

Data model:
[PASTE TYPE DEFINITION OR SCHEMA]

Generate a fixture set with:
- 3-5 standard records covering common cases
- 2-3 records with edge case values (long strings, unicode, boundary numbers)
- 1-2 records in each possible status/state
- A factory function with sensible defaults that accepts overrides

Rules:
- Culturally diverse names (not just English/American)
- All emails use @example.com (RFC 2606)
- Deterministic — no random values, every field explicit
- Include a comment above each fixture explaining its purpose
- Cover the full range of enum/status values

---

Worked Scenario Sets (what good Step-4 output looks like)

Concrete reference output for the input types this pipeline handles most often. Use these as few-shot targets — the scenario coverage, not the exact wording, is what matters.

Registration form (email, password, name)

Cover at minimum: valid registration (happy path); invalid email (a@, no @, no domain → format error); password validation / weak password (too short, no number, no symbol → rejected); empty or missing fields (each required field blank → field-level error); duplicate email / already exists (registering an email already in the DB → "account already exists"). Do not stop at the happy path.

Price-range filter (min / max inputs)

Cover: minimum / lower bound at the smallest allowed price; maximum / upper bound at the largest; a range that returns no results / empty state; boundary / edge where min == max and where min > max (invalid range → validation, not silent empty); and reset / clear filter restoring the unfiltered list.

Password-validation change (from a code diff)

When the diff tightens or changes a validation rule: assert existing behavior / backward compatible (previously-valid passwords that are still valid stay accepted; previously-rejected stay rejected); the new validation / changed rule (passwords newly allowed or newly rejected by the change); boundary / edge at the exact new threshold (e.g. min length boundary, one char under and one over); and the user-facing error message text for newly-rejected input. Scope tests to the changed code paths.

Date-range picker (start/end selection)

Cover the BOUNDARIES edges: same start and end date (zero-length range — allowed or rejected per spec); end before start / invalid range; leap year / Feb 29 (and a non-leap year Feb 29 → rejected); timezone / DST transition days (range spanning a DST shift, picker in a non-UTC locale); and min / max date limits (selecting outside the allowed window).

---

Usage Guidelines

1. Follow the pipeline order. Do not skip to Step 6 prompts. The intermediates from Steps 1-5 are the input that makes Step 6 produce good output.

2. Feed project context into every prompt. Prepend qa-project-context.md content to improve accuracy.

3. Iterate at each step. Run the Step 2 prompt multiple times with different risk perspectives. Run Step 4 with different scenario categories. Do not accept the first output.

4. Build a project-specific prompt library. Start with these templates, customize with your domain language, and version-control them.

5. Show examples of your best tests. The single most effective way to improve generated code is to include 2-3 examples of excellent existing tests as few-shot examples in Step 6.