test-master

name	test-master
description	Guides test selection, authoring, and quality review at the smallest reliable boundary. Use when: "напиши тесты", "как тестировать", "проанализируй тесты", "проверь качество тестов", "ревью тестов", "тестовая стратегия"

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.

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:

Boundary	Use when the risk depends on
Unit	One unit's calculation, decision, validation, transformation, or error behavior
Integration	An API, database, filesystem, queue, service contract, or collaborating components
E2E	A critical user journey or behavior that needs the real application stack
Smoke	Successful startup, initialization, deployment, or minimal system integration

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. 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.