Integrationstest-Plan für Feature
Entwirft einen Integrationstest-Plan für ein Feature - Szenarien, Setup, Daten, Grenzen vs. Unit-Tests.
Zuletzt geprüft 23. April 2026
Prompt
Design an integration test plan for this feature. Produce: 1. SCENARIOS - ordered by likelihood × blast radius: - Happy path (end to end, real collaborators) - 2-3 critical failure paths (DB down, upstream 5xx, partial write) - 1-2 concurrency / ordering scenarios if applicable - Security / authz boundaries if relevant 2. WHAT IS IN SCOPE / OUT OF SCOPE - In: what integration points this exercises - Out: what is covered by unit tests, what by e2e - explicit division 3. SETUP - what needs to exist (DB schema, seed data, services running, feature flags) 4. DATA - shape of test data, not literal values; where to reuse factories vs. build fresh 5. CLEANUP - transaction rollback vs. truncate vs. fresh container 6. FLAKINESS RISK - where is nondeterminism likely (time, network, IDs) and how to handle Rules: - Do not propose tests that duplicate unit tests - Do not propose mocking what the integration test exists to exercise - Flaky-by-design scenarios must have a deterministic strategy (fake clock, fixed seeds, retries) Feature: [FEATURE DESCRIPTION + CODE POINTERS] Stack: [DB, MESSAGING, EXTERNAL DEPS]
Wann nutzen
Bevor du Integrationstests schreibst. Zwingt dich zu entscheiden, welche Pfade wirklich Integration prüfen - und welche besser im Unit bleiben.
Use-Cases
- Neues kritisches Feature: Teststrategie bevor Code.
- CI-Pipeline stabilisieren: Flakes identifizieren.
- Micro-Service-Grenzen: welche Tests auf welcher Ebene?
Getestet mit
“Out of Scope” ist der wichtigste Abschnitt - er verhindert, dass Integrationstests zu end-to-end-Dampfern werden, die alles prüfen und nichts wirklich sichern.