Design and Implement Microservice Integration Tests

Microservice Integration Test Expert structures testing around service boundaries and communication patterns. It begins by mapping dependencies, distinguishing synchronous calls from asynchronous events, and identifying both successful and failing paths. Timeouts, retries, data consistency, and downstream behavior become explicit test subjects rather than incidental details of a happy-path request.

Its test pyramid separates contract tests, isolated component tests, integration tests with real dependencies, and a small set of critical end-to-end journeys. Contract tests check the agreement between consumer and provider; integration tests exercise service interactions. This distinction keeps the suite focused without trying every possible service combination at the same level.

Use the skill when designing a distributed-system test plan, adding coverage for service interactions, checking event-driven workflows, or investigating resilience failures. Tests should observe behavior rather than internal implementation details.

The supplied JavaScript classes and Compose configuration are patterns that require working services, clients, data helpers, and monitoring adapters. The Compose fragment references a payment service without defining that service. Its dependencies and illustrative credentials therefore need a deliberately isolated test environment before execution. Critical tests should avoid depending on uncontrolled external services, and parallel suites should not share mutable test data.

Inputs include a service dependency graph, API contracts, event names and payloads, timeout and retry expectations, test fixtures, and consistency rules. Outputs can include contract interactions, containerized environments, setup and cleanup utilities, failure scenarios, and detailed test reports.

A Pact interaction defines the provider state, request method, path and headers, then the expected response. The consumer client calls that interaction and asserts the returned data. A representative initialization line is:

const { Pact } = require('@pact-foundation/pact');

Event-driven tests subscribe before triggering a workflow, wait for expected events with time limits, and check payloads. Resilience tests simulate a slow downstream response, verify a bounded fallback, then trigger repeated failures and assert that an open circuit fails quickly. The demonstrated timing thresholds are test expectations to adapt, not measured service guarantees.

Distributed-state tests record starting balances and inventory, create an order, and verify the resulting updates across services. A failing insufficient-funds path checks that inventory remains unchanged. Reusable data helpers create fixtures and clean databases and caches between cases.

Docker Compose illustrates service, PostgreSQL, and Redis test dependencies. Pact covers API contracts, while autocannon supplies an HTTP load scenario with downstream monitoring. Load assertions inspect request errors, unsuccessful responses, downstream error rates, and average response time.

The skill serves people maintaining microservice test suites and CI feedback. It recommends grouping scenarios by boundary, using descriptive names, tracing distributed work, monitoring resources, collecting logs from every service, and reporting failures with useful analysis. Fast contract checks run in builds; full integration checks run in staging. Parallel execution, isolation, cleanup, and ongoing refactoring keep feedback usable as the system changes.