QE Test Generation

Purpose

Guide the use of v3's AI-powered test generation capabilities including pattern-based test synthesis, multi-framework support, and intelligent test case derivation from code analysis.

Write durable-first (the core rule)

When AI makes code cheap to regenerate, the durable asset is the test that still holds after the implementation is thrown away and rewritten. Generate tests in durability tiers, and lead with the durable ones (ADR-113):

Tier	What it is	Survives a rewrite?	When to write
Durable	Invariants, contracts/schemas, property-based tests, behavioral e2e, specified at the module's public boundary	Yes	Always, ≥1 per target
Ephemeral	Example-based unit tests, mock-call/interaction tests (TDD-London style)	No (coupled to impl)	For the red-green loop; label them, delete freely
Live	Monitoring / drift / cost assertions that run against reality	Continuously	For deployed behavior

The language-swap heuristic: if reimplementing this module in another language would invalidate the test, the test is at the wrong boundary. Push it up a tier, assert on the observable contract, not on how the current code happens to work.

Every generated target MUST include at least one durable assertion (an invariant, a contract check, or a property). Mock-call assertions (toHaveBeenCalledWith) are ephemeral by definition, never let them be the only thing testing a target. Tag each generated test // @tier durable|ephemeral|live so its lifetime is explicit.

These tests are graded as oracles: a good test passes against the real code and fails against a seeded bug (mutant). A test that asserts nothing, or only the happy path, kills no mutants and is rejected, see /mutation-testing and ADR-113.

Activation