1.5 KiB
1.5 KiB
name, description
| name | description |
|---|---|
| unit-test-write | Use when adding or changing tests for one isolated function, component, or decision. Use integration-test-write when behavior must cross an application or service boundary. |
Unit Test Write
Use when adding or updating tests for one isolated function, component, or decision.
Workflow
- Read the requirement and implementation. Identify the observable result that defines success and the boundary conditions most likely to fail.
- Follow the repository's existing test framework, naming, setup, and assertion style. Avoid new dependencies or fixtures when a small test can express the behavior. If test APIs, mocks, or expected outcomes depend on external behavior, MUST apply the implementation checkpoint in
technical-researchbefore encoding that assumption. - Cover the normal case and the smallest meaningful set of boundary or failure cases. Include a regression case for a reported defect.
- Assert public behavior and useful error outcomes rather than private call order, incidental wording, or internal data layout.
- Keep each test deterministic. Control time, randomness, filesystem state, and external services when they affect the result.
- Run the focused test and report its result. MUST apply the verification checkpoint in
technical-researchto any external claims the result relies on. Broaden verification only when shared behavior or connected components are affected.
Do not add tests that duplicate existing coverage or require production code to expose test-only hooks without a clear reason.