What problem does it solve?
Integration-Test Design prevents flaky, misleading, or ineffective test suites by helping you explicitly design what an integration test scope is (and isn’t), and by choosing real-vs-faked collaborators and test data lifecycles that keep boundaries honest.
Core Features & Use Cases
- Boundary-first scope definition: designs integration tests around the seam between two or more units (module, layer, service, process boundary) so the test catches boundary defects rather than merely re-testing unit logic.
- Real-vs-faked collaborator decisions: determines when to use real dependencies (e.g., databases, message buses, caches) versus recorded or capture fakes (e.g., paid/side-effect third parties).
- Test data lifecycle patterns: applies standard isolation methods such as transaction rollback or container reset to reduce shared-state flakes.
- Failure-mode diagnostics: identifies common causes of “integration tests that act like unit tests” or “integration tests that act like e2e tests,” plus flake sources like shared mutable state and ordering/time dependencies.
Quick Start
Use the integration-test-design skill to design an integration test for the order service by specifying the boundary, selecting which collaborators are real versus faked, and choosing a test-data lifecycle (typically transaction rollback).
