1.7 KiB
1.7 KiB
name, description
| name | description |
|---|---|
| integration-test-write | Use when adding or changing tests for behavior across a real boundary, such as an API and database, filesystem command, or cooperating services. Not for isolated unit behavior. |
Integration Test Write
Use when verifying behavior across a real application boundary, such as an API and database, a command and filesystem, or cooperating services.
Workflow
- Name the boundary under test and the production path the test must exercise. Keep unit-level details covered by unit tests.
- Reuse the repository's integration-test setup. Before relying on external service, driver, or test-framework behavior, MUST apply the implementation checkpoint in
technical-research. Start only the services and data stores required for this behavior. - Prepare minimal isolated data and control external inputs. Prevent test runs from touching user data, shared environments, or live services.
- Cover a successful interaction and the failure or rejection path that matters to the change. Include transaction, retry, or cleanup behavior only when it is part of the contract.
- Assert persisted or externally observable outcomes, including relevant status, response, and side effects.
- Clean up created resources even when assertions fail. Make repeated runs safe and independent.
- Run the focused integration test and report required services, results, and any unavailable environment. MUST apply the verification checkpoint in
technical-researchto external contract claims; a mock or documentation excerpt cannot prove the real boundary works.
Avoid turning an integration test into a full end-to-end suite when a narrower boundary proves the contract.