unit-test-author

Unit Test Author

Overview

This skill produces unit tests that are correct, behavior-focused, exhaustive on edge cases, and resistant to brittleness. It applies across languages and frameworks and emphasizes testing observable behavior over implementation details.

Keywords: unit test, test coverage, edge cases, table-driven, parametrize, mock, stub, spy, fake, fixture, AAA arrange-act-assert, flaky test, property-based, snapshot, regression test, pytest, Jest, Vitest, Go test, JUnit, RSpec, xUnit, NUnit, Rust test.

Use this skill whenever the goal is to create or strengthen unit tests for a specific function, class, or module — not for end-to-end or load testing.

Core Principles

1. Test behavior, not implementation. Assert on outputs, return values, raised errors, and observable side effects — never on private internals that can change without breaking the contract.
2. One logical concept per test. A test may have several assertions, but they should all verify a single behavior. If a test name needs "and", split it.
3. Deterministic always. No real clocks, randomness, network, filesystem, or ordering assumptions unless explicitly under test. Inject or freeze them.
4. Arrange-Act-Assert (AAA). Visually separate setup, the single action, and verification. Keep the "act" to one call.
5. Fail for one reason. When a test fails the message should point to the cause. Prefer precise assertions over assertTrue(x == y).
6. Cover the contract, then the edges. Happy path first, then boundaries, then error/exception paths.

Workflow

Follow these steps in order. Do not skip step 1 — understanding the unit under test prevents tautological tests.

1. Identify the unit and its contract. Read the function/class. List: inputs (types, ranges), outputs, raised errors, side effects, and dependencies (collaborators to mock).
2. Detect the framework and conventions. Inspect the repo: test directory layout, existing test files, the runner (package.json scripts, pytest.ini/pyproject.toml, go.mod, pom.xml, Cargo.toml), assertion library, and mocking library already in use. Match existing conventions. See references/frameworks.md.
3. Enumerate test cases using the edge-case checklist in references/edge-cases.md. Produce a short list before writing code (happy path, boundaries, empties, nulls, errors, concurrency if relevant).
4. Choose a structure. When many inputs map to one behavior, use table-driven / parametrized tests (see references/table-driven.md). Otherwise, individual named tests.
5. Plan the test double strategy for each dependency (mock vs stub vs fake vs spy) using the decision guide in references/mocking.md. Mock at architectural boundaries (network, DB, time, randomness), not internal pure functions.
6. Write the tests with descriptive names (method_condition_expectedResult), AAA layout, and precise assertions.
7. Add error-path and edge tests explicitly — these are most often missing.
8. Run the tests and ensure they pass. Then sanity-check quality with scripts/check_tests.py (heuristic linter for missing assertions, skipped tests, sleep-based timing, etc.).
9. Verify they actually test something: mentally (or literally) mutate the implementation and confirm a test would fail. Tests that pass against a broken implementation are worthless.