tester

name	tester
description	Test authoring and test-strategy skill. Activate when writing new tests, planning a test strategy, enumerating edge cases for a feature, or reviewing whether a change has adequate coverage. Optimised for high-signal tests that catch regressions, not coverage theatre.
license	Apache-2.0
metadata	{"provenance":{"canonical":"https://github.com/hcross/crewrig","feedback":"https://github.com/hcross/crewrig","version":"1.1.0"}}

Tester

Tests exist to catch regressions and to document behaviour, not to inflate a coverage number. Bias toward fewer, sharper tests.

When to activate

• A feature is being added and the project's convention requires tests.
• A bug fix lacks a regression test.
• The user asks for a test plan or edge-case enumeration.
• A diff is up for review and you suspect under-tested behaviour.

If the project has no test infrastructure and the user has not asked for one, do not invent one — say so and move on.

Operating mode

1. Identify the unit of behaviour

Pick the smallest observable behaviour to test, not the smallest function. A function with no observable contract has nothing to test. A file-level helper called only from one place is best tested through the caller.

2. Golden path + edge cases (not exhaustively)

For each behaviour, plan:

• One golden-path test that exercises the success case.
• One or two edge-case tests for the failure modes that matter.
• A regression test if the test was triggered by a bug fix — named so it is obvious which bug it guards.

Edge cases to consider, in this order of priority:

1. Empty / null / zero-length input.
2. Boundary values (off-by-one, overflow, encoding edges).
3. Known-bad input (malformed, adversarial — see security skill).
4. Concurrent / repeated invocations if the surface is stateful.
5. Partial failure (network mid-call, disk full, signal interrupt).

Stop adding cases when the marginal case becomes contrived. Coverage of contrived cases costs maintenance forever.

3. Real dependencies where it matters

For integration tests:

• Hit a real database when the project's convention is integration testing (use Testcontainers, Docker Compose, or the project's scaffold). Mocked DB tests have a known failure mode where they pass while the real schema is broken.
• Mock an external API only when its calls are non-deterministic, slow, or rate-limited. Otherwise prefer a recorded fixture (VCR-style).

If the project has explicit guidance ("don't mock the database"), follow it without rediscovering the lesson.

4. Test naming and structure

Name tests by behaviour, not by function:

✓ test_login_with_valid_credentials_returns_session_token
✗ test_login_function

Structure each test as arrange / act / assert, with a blank line between each phase. Multi-assertion tests are fine when the assertions together describe one behaviour; split when they describe two.

5. Verifying a fix

When the trigger is a bug fix:

1. Write the test first. Run it. Confirm it fails for the right reason — not a setup error.
2. Apply the fix.
3. Run the test. Confirm it passes.
4. Run the rest of the suite to detect regressions in unrelated areas.

A test that never failed before the fix proves nothing.

Output expectations

• Tests committed alongside the change they cover, never in a separate PR (unless the project explicitly batches test PRs).
• A one-line comment above each test stating the why — the behaviour being asserted — only when the test name alone is not self-evident.
• Test data inline when small; in fixtures when reused or large.

Friction reporting

When a recognition signal fires (see config/TOOLS.md → Friction Reporting → Recognition signals), invoke the harness-report skill rather than reimplementing the protocol inline. The reporter walks you through identifying the offender, picking the room, and filling the payload.