Test Skill

Generate real tests, run them, and leave reproducible coverage or TDD evidence. Do not stop at a plan unless the requested mode is strategy.

Critical Constraints

• Why: behavior is the contract. Derive tests from acceptance scenarios and public behavior, not implementation details or coverage percentages alone.
• Why: prove new behavior. In TDD mode record a real failing test before the minimal implementation; a test that starts green is not RED evidence.
• Why: avoid false confidence. Assert exact values, error types/messages, and branch outcomes; ban zero-assertion, tautological, and padding tests.
• Why: keep suites trustworthy. Tests must be deterministic, isolated, and independent of timing, ordering, production services, or mutable shared state.
• Why: protect user intent. Report a product bug discovered by a test; do not silently change product behavior or delete existing tests without approval.
• Why: close with proof. Run the narrow test after each edit, then the relevant suite and coverage command before handing work downstream.