Test Master

Decide What to Protect

Tests protect observable behavior or another explicit contract that must survive change. Trace each selected scenario to the user request, user-spec, or changed project contract.

Automated tests apply only to deterministic executable code; LLM-produced results and presentation-only layout use agent, manual, or visual verification instead.

Freely editable copy, presentation-only markup or styles, constants that merely repeat their source value, and framework behavior normally have no test subject. They become testable when an explicit user, accessibility, legal, safety, protocol, or project requirement makes their presence or semantics invariant. Test that contract at an observable boundary rather than freezing implementation shape or exact wording.

Choose the Smallest Reliable Boundary

Protect each distinct risk once at the smallest boundary that can reproduce it:

Do not repeat the same risk at several levels for pyramid completeness. A characterization test may pass before a refactor when its purpose is to prove existing behavior remains unchanged.

When authoring a selected type, apply its conditional guide:

• unit-tests.md — unit structure, dependency boundaries, and mocking;
• integration-tests.md — real component boundaries, fixtures, external services, and cleanup;
• e2e-tests.md — journeys, environment, selectors, and execution;
• smoke-tests.md — minimal startup and infrastructure coverage.

Authoring Rules

• Test observable results, state, errors, or required outgoing interactions rather than private implementation shape.
• Cover the changed happy path, meaningful branches, failure paths, and specified edge cases without duplicating an already protected risk.
• Keep tests independent and deterministic with known state. Replace dependencies only outside the boundary the test is meant to exercise.
• Several mocks are a signal to inspect the boundary, not a defect by count. A test fails when mocks replace the meaningful decision or merely replay configured values.
• Use clear scenario names and minimal fixtures. Run the selected tests and separate unrelated baseline failures from regressions.

Test Review

When meaningful test code changes, run a fresh test-reviewer in full mode after implementation. Supply the changed tests and implementation, behavior requirements and contracts, direct validation evidence, and a short explanation of what changed, how the tested behavior works, why the test boundary and scenarios were chosen, deliberate limits, and assumptions. The reviewer verifies that explanation as a claim rather than accepting it as authority. It may challenge the test approach or boundary and propose a better boundary or additional scenario when supported by the test-quality evidence.

For a user-requested review of existing tests, apply test-quality-review.md — demonstrated coverage gaps, boundary problems, and ineffective tests.

Reviewer severity follows the concrete regression that can pass undetected, not the category or appearance of the test problem. Naming preferences and optional improvements without concrete impact are not findings.

After the review, do not add or change tests from its findings and do not repeat the review automatically. Explain what tests you changed and what behavior they prove, then what the reviewer found, what it can cause, whether you agree and why, and what you recommend. Wait for the user's approval before editing.