test-design

Test Design

Purpose

Create tests that document expected behavior, catch regressions, and remain stable as implementation details change.

When to use it

• Whenever you add or change behavior.
• When a bug is found (write a failing test first, then fix).

Instructions

1. Derive cases from requirements and edge cases, not from the implementation.
2. Cover happy paths, error paths, boundaries, and empty/large inputs.
3. Assert observable behavior and meaningful content.
4. Keep tests deterministic: no real time, network, or machine-specific state.
5. Name each test after the behavior it verifies.

Output format

Test files with clear names and assertions, plus a short mapping from tests to requirements.

Anti-patterns

• Asserting only existence ("file was created") without checking content.
• Coupling tests to internal details that should be free to change.
• Weakening a test to make a broken implementation pass.

Verification checklist

• Include positive, negative, boundary, malformed, empty, and large-input cases that are relevant to the requirement.
• Prove the regression test detects the old defect when practical.
• Keep fixtures minimal and isolate time, randomness, network, and filesystem state behind deterministic controls.

Apply context-discovery before broad scanning: use a supplied context capsule first; otherwise check context frontmatter freshness, read .agent/context/routing.md, load only relevant summaries, and verify critical claims against source.