review-test-harness

name	review-test-harness
description	Review changes to tests, fixtures, or integration harnesses. Use when a PR adds, modifies, or removes tests, or when test expectations, stubs, or environment setup change.

Review Test Harness and Fixture Changes

Use this skill when reviewing or authoring changes to any file under tests/, scripts/ that builds fixtures, or integration harness startup code.

Why this exists

~15% of fix commits are test harness drift: failing expectations, architecture path string mismatches, fixture module refactors, and integration harness startup flakiness. This skill prevents that tax.

Pre-merge checklist

1. No path-string or formatting assertions

• Tests do not assert on file paths, module URLs, or string formatting that can drift during refactors.
• If a test must verify a path, use a behavior-based check (e.g., "module loads without error") or a stable identifier, not a string match.

2. Expectations are behavior-based

• New or updated assertions check what the code does, not how it is structured.
• Example: prefer expect(renderer.getScale()).toBe(1.5) over expect(logOutput).toContain("scale=1.5").

3. Integration harness contract is versioned

• If changing tests/environment/*.ts, tests/setup.ts, or the agent integration harness, document the startup contract in a comment or doc.
• Changes to the harness that break downstream tests must update the contract doc and notify owners of affected test files.

4. Fixtures are deterministic

• Any new fixture or snapshot is generated by a script (e.g., scripts/capture-certification-corpus.ts) rather than hand-edited.
• The generation script is referenced in the fixture's README or header comment.

5. Regression tests for fixed bugs

• If the PR fixes a bug, it includes a regression test that fails before the fix and passes after.
• The regression test is named after the bug (e.g., test('blend alpha parity for shapes — regression #911')).

6. Test file ownership is clear

• If a new test file is added, it follows the existing naming convention and lives in the directory matching the source it covers.
• Cross-directory test imports are minimized; prefer testing through public seams.

What to reject in review

• Tests asserting on __dirname, import.meta.url, or architecture violation source paths as strings
• Hand-edited snapshots or fixtures without a generation script
• Integration harness changes that require co-fixing >3 unrelated test files
• Missing regression tests for parity or fallback bugs

Related skills

• verify-visualizer-work — for iterative validation during implementation
• test-visualizer — for running the full test suite