test-author

name	test-author
description	Create or update targeted tests for changed behavior. Use when adding features, fixing bugs, refactoring code, or finding missing coverage, especially when existing tests need to be extended to cover new behavior, edge cases, or regressions.

Test Author

Author tests that match the project’s existing conventions and protect changed behavior. Prefer small, focused tests that a maintainer would keep, not broad generated coverage for its own sake.

When to use

Use this skill when:

• adding or changing behavior
• fixing a bug that should become a regression test
• refactoring code while preserving behavior
• reviewing code and noticing missing or weak coverage
• updating APIs, data transformations, validation, permission logic, background jobs, or error handling

Do not create tests blindly. First understand the behavior, the project’s test framework, and nearby test patterns.

Workflow

1. Identify the behavior to protect

State the behavior in concrete terms:

• inputs and setup
• action under test
• expected output or side effect
• error path or edge case
• regression being prevented, if any

If the expected behavior is ambiguous, ask before writing tests.

2. Discover project conventions

Inspect the narrowest relevant scope:

• package config (package.json, pyproject.toml, go.mod, etc.)
• existing tests near the changed code
• test helpers, fixtures, factories, mocks, and custom assertions
• naming, file placement, setup, teardown, and validation commands

Follow the project’s existing framework and style unless there is a clear reason not to.

3. Choose test shape

Prefer:

• extending an existing test file when the behavior belongs there
• creating a new test file only when no appropriate home exists
• testing public behavior over implementation details
• table-driven or parameterized tests for repeated cases
• realistic fixtures with explicit values
• mocks only at system boundaries such as network, database, filesystem, clock, or external services

Avoid:

• brittle snapshots for complex output unless the project already relies on them
• testing private helpers directly when public behavior is sufficient
• duplicating production logic in assertions
• broad mocks that make the test pass without exercising the behavior
• unrelated cleanup or formatting changes

4. Cover the right cases

Consider:

• happy path
• boundary values
• missing, null, empty, malformed, or unexpected inputs
• documented error handling
• permission or auth branches
• retry, timeout, cancellation, and idempotency behavior where relevant
• serialization, parsing, and validation at system boundaries
• regressions tied to the original bug or change

Prioritize high-signal cases. More tests are not automatically better.

5. Validate narrowly

Run the narrowest project-native command that proves the tests work, for example:

• a single test file
• a package test command
• a related typecheck or lint command if test changes affect types or formatting

If validation fails because of pre-existing unrelated failures, report that clearly and do not fix unrelated files unless asked.

Output expectations

When proposing or summarizing test work, include:

## Behavior covered
- <specific behavior or regression>

## Tests added or updated
- `path/to/test`: <what it verifies>

## Validation
- `<command>`: <result>

## Notes
- <assumptions, uncovered cases, or follow-up recommendations>

Principles

• Tests are executable specifications. Make them readable.
• Match the codebase before introducing new testing patterns.
• Protect user-visible behavior and system boundaries.
• Keep diffs small and reviewable.
• Prefer one precise regression test over broad low-signal coverage.