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.