A verification harness is a set of sensors
A verification harness is a local set of repeatable checks that turns assumptions about change safety into measurable signals. It reveals formatting, type, compilation, test, static-analysis, or obvious security-pattern problems.
A sensor must be deterministic: the same code state should produce the same result. An unstable test is not a reliable basis for a refactoring decision.
| Sensor | What it detects |
|---|---|
| Formatter | Style and formatting-structure problems |
| Linter | Common mistakes and questionable patterns |
| Type-check | Broken type contracts and signatures |
| Build / assemble | Compilation, dependency, and module problems |
| Unit / integration tests | Local logic and component interaction |
| Coverage / static analysis | Blind spots and deeper quality signals |
| Code intelligence | Declarations, usages, call chain, and impact size |
Fast and full checks
You do not need to run the entire CI after every file save, but do not postpone every check until the end either. A formatter can show correct style, but it does not prove correct behavior.
| Group | Examples | When to run |
|---|---|---|
| Fast | Formatter, light lint, type-check, targeted unit test | After every small step |
| Medium | Integration test, build of one module | After changing the relevant layer |
| Full | Full test run, coverage, broad static analysis | Before a PR or stage completion |
Map the harness before editing
- Read CLAUDE.md and project rules.
- Check package.json, build.gradle, README, and existing scripts.
- Separate fast checks from full checks.
- Do not add a new toolchain when the necessary tools already exist.
- Find usages, the call chain, related tests, and public contracts.
- Record unknown commands instead of inventing them.
A controlled harness cycle
- Make one bounded change.
- Run the appropriate targeted sensor.
- Review the diff and file list.
- Before the PR, run a broader set of checks.
- Save the actual commands, results, and limitations.
one approved change
-> targeted sensor
-> diff review
-> record command and result
-> broader harness before PRExample for a local refactoring
Before changing OrderService.finalizeOrder, find all calls and tests. After moving validation into a private helper, run a targeted test, read the diff, and run a fuller check before the PR. The tester-agent and reviewer-agent should use the same harness instead of inventing their own criteria.
- Mark an unknown script as unknown.
- A failed sensor is a diagnosis signal, not a reason to weaken a test immediately.
- Record what actually ran when the work is complete.
- Do not call a check successful without an actual result.
Canonical lesson source · JavaRush
Open JavaRush material