home / skills / shotaiuchi / dotclaude / test-unit

test-unit skill

This skill helps you create thorough unit tests for individual functions and classes with proper mocks, assertions, and coverage.

npx playbooks add skill shotaiuchi/dotclaude --skill test-unit

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.8 KB

---
name: test-unit
description: >-
  Unit test creation. Apply when writing isolated tests for individual
  functions, methods, and classes with proper mocking, assertions, and
  coverage of happy paths and error conditions.
user-invocable: false
---

# Unit Tests

Write unit tests for individual functions, methods, and classes in isolation.

## Test Creation Checklist

### Function/Method Isolation
- Identify all external dependencies to mock or stub
- Ensure each test exercises exactly one unit of behavior
- Verify test independence (no shared mutable state between tests)
- Check that setup/teardown properly resets test context
- Confirm no reliance on execution order

### Assertion Completeness
- Assert return values for all meaningful inputs
- Verify state changes on mutable objects after method calls
- Check that expected exceptions are thrown with correct types and messages
- Assert side effects (method calls on collaborators, events emitted)
- Validate output structure, not just existence

### Happy Path Coverage
- Cover the primary success scenario end-to-end
- Test with typical/representative input values
- Verify correct behavior with valid boundary inputs
- Check default parameter behavior
- Test idempotent operations for consistent results

### Error Condition Coverage
- Test with invalid, null, and out-of-range inputs
- Verify graceful handling of dependency failures
- Check timeout and cancellation behavior
- Test concurrent access if applicable
- Validate error messages and error codes returned

## Output Format

Report test plan with priority ratings:

| Priority | Description |
|----------|-------------|
| Must | Core functionality tests that prevent regressions |
| Should | Important paths that cover common usage patterns |
| Could | Additional coverage for less common scenarios |
| Won't | Out of scope or covered by other test types |

Overview

This skill helps create focused unit tests for individual functions, methods, and classes with clear mocking, assertions, and prioritized test plans. It emphasizes isolation, complete assertions, and coverage of both happy paths and error conditions. The output is a prioritized test plan suitable for immediate implementation in a test suite.

How this skill works

It inspects function signatures, dependencies, and side effects to identify what to mock or stub and which behaviors to assert. It produces a checklist and a prioritized test matrix (Must/Should/Could/Won't) covering return values, state changes, exceptions, side effects, boundaries, and failure modes. The skill outputs concise test cases and setup/teardown guidance to ensure independence and reproducibility.

When to use it

Writing unit tests for newly implemented functions or recently refactored code
Before adding integration tests to ensure core logic is verified in isolation
When introducing mocks/stubs for external dependencies (I/O, network, databases)
Preparing regression tests for bug fixes to prevent reintroduction
Validating edge cases, error handling, and boundary conditions

Best practices

Isolate a single behavior per test and mock all external dependencies
Keep tests independent: avoid shared mutable state and use explicit setup/teardown
Assert both return values and observable side effects, including collaborator calls
Cover happy paths first with representative inputs, then add error and boundary tests
Prioritize tests using Must/Should/Could/Won't to focus effort on preventing regressions

Example use cases

Create Must-priority tests asserting core return values and primary side effects for a payment processing function
Write Should tests for typical invalid inputs, null handling, and dependency failures
Add Could tests for rare concurrency scenarios and extended boundary conditions
Produce a test checklist for a refactor to guide developers on required mock coverage and assertions
Generate setup/teardown snippets for shell-invoked helpers and environment-controlled tests

FAQ

How do I decide what to mock?

Mock external systems, I/O, and slow or non-deterministic dependencies. Keep collaborators mocked so each test exercises only the unit under test.

What makes a test Must priority?

Must tests cover core functionality that would cause regressions if broken: main return values, essential side effects, and error conditions users rely on.

How many assertions per test are acceptable?

Prefer a small number of focused assertions that validate a single behavior; use multiple assertions when they verify different observable aspects of the same behavior.