| name | selective-testing |
| description | Use to test implementation proportional to impact — from changed files to affected components to the relevant tests — instead of running the whole suite after every task. Records the test evidence later stages can reuse. |
Selective Testing
Purpose
Make testing fast and meaningful during implementation by focusing effort where
the change actually lands, while still proving each task works.
When to use
After a task is implemented, before accepting it — and when deciding how much to
test at feature completion.
Procedure
- Check the ledger first. Before running anything, ask
aspis tests check <the code/test files>. If it reports cached: pass, those files
are unchanged since they last passed — reuse that result and skip the run. Only run
when it reports stale. Don't re-test what hasn't changed.
- Trace the impact. Changed files → affected components → the tests that cover
them. Test that set first.
- Run task-level tests. Unit and targeted tests for the change, plus the
integration or smoke tests its components touch.
- Scale to risk. Higher-risk or cross-cutting changes widen the net; small,
isolated changes stay narrow.
- Run the full gate at the right moments. Reserve the whole-suite run for
feature completion or when impact is broad — not after every task.
- Record evidence. After a run,
aspis tests record <files> --result pass|fail so
the next task/review reuses it; capture what ran for the build/review report.
Outputs
- Targeted test results per task and recorded evidence for later stages.
Anti-patterns
- Running the entire suite after every trivial change.
- Skipping tests for "obvious" changes.
- Testing only the changed file while ignoring the components it affects.
- Discarding results that later stages would have reused.
