What is the testing scope for microservices?

Testing microservices requires a strategy adapted to their distributed nature. The testing honeycomb (Spotify model): Unit tests: test domain logic in isolation — fast, plentiful. Integration tests: test service internals (service → database, service → cache) — use Testcontainers. Contract tests: verify API contracts between services — use Pact (consumer-driven). These replace the need for full end-to-end tests across many services. Component tests: test a service in isolation with all its real internal dependencies but with external services stubbed — use WireMock/stubby. System tests (E2E): test critical end-to-end journeys across multiple services — kept minimal. Key principles: (1) Don't test other teams' services — trust their tests + contract tests. (2) Don't integrate in CI unless necessary — use contracts. (3) Each service owns its own tests. (4) Test environment parity: staging environment for E2E. (5) Consumer-driven contracts: consumers define what they need from providers — prevents provider breaking changes. Most testing value comes from unit + integration + contract tests.