Integration testing in microservices focuses on how services work together rather than on individual components in isolation. Because services can be deployed independently and communicate over networks, integration tests are essential for catching issues that unit and service-level tests miss.
Integration Testing Patterns
Common patterns include service-to-service integration tests, API gateway tests, and workflow tests that span several services but stop short of full UI flows. These tests often run in environments where a subset of services is deployed with realistic configurations. They validate contracts, data flow, and error handling between services.
# Example integration pattern: order placement
- Call Order API to place an order.
- Verify Order service publishes an event.
- Check Inventory service updates stock.
- Confirm Notification service sends a message.Choosing which interactions to test depends on risk, change frequency, and criticality. You might focus on payment flows, inventory updates, or identity management, where failures would be highly visible or costly.
Scoping Integration Tests
Define clear boundaries for each integration test: which services are in scope, which are mocked or stubbed, and what success looks like. This helps keep tests maintainable and easier to debug when failures occur.
Common Mistakes
Mistake 1 — Over-mocking or under-mocking dependencies
Both extremes distort test results.
❌ Wrong: Mocking everything (no real integration) or nothing (too fragile).
✅ Correct: Mock only where necessary and test critical real integrations.
Mistake 2 — Letting integration tests grow without structure
This leads to slow, opaque suites.
❌ Wrong: Adding scenarios ad hoc without grouping or naming conventions.
✅ Correct: Organise tests by workflow or capability with clear documentation.