strategic-testing

Identify the realistic failure the test would prevent and check whether existing coverage, types, linting, or schema validation already catch it. Add a test only when it protects meaningful behavior or a stable contract that current checks could miss.

Prioritize tests for domain invariants, important edge cases, public interfaces, persisted data, security boundaries, and integration seams. These areas carry behavior that other verification layers typically cannot protect.

Skip tests for mechanical edits, implementation details, and changes already covered by existing tests or verified by the type system, linter, or schema validation. If the failure case is weak, the maintenance cost is not justified.

Choose the smallest test level that still protects the behavior in question. Use a unit test when the risk lives in isolated logic, and move to integration tests only when the behavior spans component or system boundaries.

No. Coverage tools measure which lines execute, while this Skill judges whether a test protects meaningful behavior. Use it alongside coverage metrics to avoid chasing percentage targets with low-value tests.