| name | check-test-strategy |
| description | Phase 7 test selector — decide which test types a task requires (unit always; integration, regression, e2e, performance, security conditionally) from its characteristics, and emit them as harness verifications. Use when: choosing test types for a child-task at plan time, freezing a task's --verifications before start, or deciding whether IT/regression/e2e/perf/security apply. |
One-Liner
Pick the test types from the task's characteristics and freeze them as immutable --verifications
at plan time — unit always, the rest conditionally — because the selection is locked at start.
Input: a child-task's plan + design context. Output: the required test set and the matching
--verifications commands, frozen at plan time (see plan-tasks).
Selection matrix
Answer each question for the task; include the test type when the condition holds:
| Test type | Required when | Skill |
|---|
| Unit (UT) | always | test-unit |
| Integration (IT) | crosses components or calls an external dependency | test-integration |
| Regression | the change touches existing behavior (edits/refactors live code, DB migrations) | test-regression (F18) |
| E2E | a user-facing end-to-end flow exists (from design-ux-flow) | test-e2e (F18) |
| Performance | a latency/throughput NFR is stated for the task | test-performance (F18) |
| Security | auth, secrets, sensitive data, or an external attack surface is involved | test-security + a check-security-review pass |
Emit verifications
Map each selected type to a runnable command for the project's stack and write them at add time:
./harness add F<id>-T<n> "<task>" ... \
--verifications "unit:<cmd>" "integration:<cmd>" "regression:<cmd>" ...
Because harness locks verifications at start, the selection must happen now (phase ④). Record
the rationale ("IT included because the task calls the payments API") in the task plan.
Gate: the selected test types are written as --verifications (with rationale) before the
task is started — the set is immutable afterward.
Enforced at verify
At harness verify, evidence ## Test is checked by hooks, so record the prescribed formats:
- every recorded
<type>: verdict must read PASS (test-type-coverage-gate);
- if integration is selected, an
### Integration Test Cases table with concrete Steps +
Expected Output is required (it-testcase-gate, per test-integration);
- if e2e is selected, an
### E2E Coverage Matrix proving every flow COVERED is required
(e2e-coverage-gate, per test-e2e).
Persona
- Non-Technical — do not surface the matrix; just run the selected tests and report pass/fail plainly.
- Developer — show the selected set + the reason per type for review.
Rule
Under-selecting tests is a quality failure, not a token saving — when a condition is borderline,
include the test (../../resources/token-budget.md).
