Design a Test Pyramid for a Microservices Architecture
Reads a microservices topology (services + integration points) and returns a recommended pyramid distribution with concrete percentages per layer, layer-by-layer justification, explicit contract-test placement at every service boundary, and a strategy for async events.
When to use it
- Designing the test strategy for a new microservices system.
- Auditing an existing test suite that feels like an ice cream cone (too many E2E, too few unit tests).
- Justifying investment in contract testing to engineering leadership.
- Onboarding teams new to microservices testing patterns.
The prompt
XML-tagged — best for Claude 4.x
<role>
You are a distributed-systems test architect. You know that microservices testing fails when teams treat the pyramid as suggestive instead of prescriptive, and when contract tests get skipped because they "felt heavy". You enforce explicit percentages and explicit contract-test placement.
</role>
<context>
Microservices pyramid: Unit (largest) → Integration (component-level) → Contract (service boundaries) → E2E (smallest). The contract layer is mandatory at every service boundary; without it, integration is just hope. E2E covers cross-cutting business journeys, not unit-level concerns. Async events (Kafka, RabbitMQ) deserve their own contract pattern.
</context>
<task>
For the topology I provide:
1. Recommend percentages per layer (sum to 100%) for the SUITE composition, not for runtime.
2. Justify each layer's percentage with a 1-2 sentence rationale.
3. Identify EVERY service boundary; place a contract test recommendation at each.
4. Address async event boundaries with a contract pattern (event schema, Pact-style consumer-driven, or producer-driven).
5. Flag any anti-pattern in the topology (mono-service called from too many places, missing API gateway, etc.).
</task>
<input>
Topology (services + integration points): {topology}
Current test suite shape (if known): {current}
Team size: {team}
</input>
<constraints>
- Percentages sum to 100%; show numbers, not L/M/H.
- E2E layer is SMALLEST. If your recommendation puts E2E > 10%, justify aggressively.
- Contract test at every sync boundary (HTTP, gRPC) AND every async boundary (events).
- Address ice-cream-cone anti-pattern explicitly if current suite is described.
- Don't recommend a tool without explaining why (Pact vs spec-based vs schema-only).
</constraints>
<output_format>
Five sections:
1. **Pyramid (ASCII diagram with percentages)**
2. **Layer rationale** — one paragraph per layer
3. **Contract test placement** — table: Boundary | Type (sync/async) | Recommended approach
4. **Anti-patterns spotted** — bullets (or "None observed" if clean)
5. **Migration path** (if current suite is provided) — order to shift the mix
</output_format>
Before writing, count service boundaries and async streams in the topology.Example
Common pitfalls
- Model recommends 'balanced' 25/25/25/25 percentages — that's an anti-pattern. Force E2E < 10%.
- Contract tests get listed as 'recommended' without naming a specific approach per boundary.
- Async event testing gets glossed over — explicit async pattern is mandatory.
- Migration path skips ordering — without sequence, teams try to do everything at once and stall.
Tips
- Re-run quarterly; team and topology drift.
- Pair this prompt with `risk-based-testing-prioritization` to allocate the limited contract-test budget to the highest-risk boundaries first.
- Read 'Testing Microservices' by Cindy Sridharan if your team needs deeper conviction; this prompt summarizes principles, but the book has the war stories.
- Resist pressure to add 'just one more' E2E test. Every E2E added has compounding cost; budget enforcement is the only mechanism that works.
FAQ
Rarely. The most defensible case: a UI-heavy monolith where backend is so thin that E2E covers most behavior. For microservices, ice cream cone always signals an architecture problem (services too tightly coupled to test individually).
Related prompts
Create API Test Suite from OpenAPI Spec
Reads an OpenAPI 3.x specification and returns an API test suite that validates response schemas per documented status code, covers authentication, pagination, filtering, and the standard error responses (400, 401, 403, 404, 429, 500). Output is framework-agnostic plan plus Playwright APIRequestContext skeleton.
Open →Generate Test Strategy Document
Returns a full Test Strategy document with 8 mandatory sections — scope, test levels, test types, entry/exit criteria, risk matrix, environment, resources, deprioritized test types — tailored to a product description and stated constraints.
Open →Test Impact Analysis from Git Diff
Reads a git diff and an import graph and returns the minimal test set to run for that diff — direct hits, transitive impact (1-2 levels), and explicit full-suite triggers (config / migration / lock file changes).
Open →Create Test Plan from PRD
Reads a Product Requirements Document and returns a release-specific Test Plan with scope, milestones, RACI per major activity, deliverables, entry/exit criteria, risk assessment, and a defect management workflow. Uses date placeholders the user fills rather than fabricating.
Open →