Component Test
Tests that verify complete business cases through your public API with real infrastructure but mocked external services.
A component test verifies a complete business case by calling your service through its public API (HTTP, gRPC) with real infrastructure, while mocking external services.
The key distinction from other test types:
- Unit tests check isolated pieces of logic. Fast, cheap, but don't verify how pieces work together.
- Integration tests verify your code works correctly with infrastructure you control, like your database. They test that your repository can save and load data, not that your business logic is correct.
- Component tests spin up your entire service with all internal layers working together. They answer questions like: "When I book a ticket via the HTTP API, is a receipt issued and the spreadsheet updated?"
Component tests mock external services but use real databases and message brokers. External services would add flakiness and slow down the feedback loop. Your own infrastructure is stable enough to include.
This approach gives you high confidence that your business logic works end-to-end, without the brittleness of full end-to-end tests that depend on every service being available. In practice, a good set of component tests can eliminate the need for most E2E tests.
References
- Microservices test architecture. Can you sleep well without end-to-end tests? — Introduces component tests as a way to verify all layers of a single service working together, with real infrastructure but mocked external services. Explains why component tests give high confidence without the brittleness of end-to-end tests.
- 4 practical principles of high-quality database integration tests in Go — Distinguishes integration tests (verifying infrastructure like databases) from component tests that verify business logic across all layers. Recommends covering as much as possible at lower levels: unit, integration, and component tests.
- Running integration tests with docker-compose in Google Cloud Build — Shows how to run component tests in CI using docker-compose, with separate environment configurations for local and CI component tests. Component tests spin up services on demand and use different ports than end-to-end tests.
- Increasing Cohesion in Go with Generic Decorators — Recommends testing authorization mechanisms at the component tests level, where you can verify the full request lifecycle through the public API.
- Distributed Transactions in Go: Read Before You Try — Suggests using component tests to test event handler behavior through the public API, rather than testing event handler code directly.
- Event-Driven Architecture: The Hard Parts — Discusses how component tests are compatible with event-driven architectures, letting you test the broker the same way you run it in production. Explains that component tests fill the gap between end-to-end and integration tests.
- Is Clean Architecture Overengineering? — Explains that application layer logic should be covered by component tests, which call through all layers and verify everything is integrated correctly.
- AMA #1: Clean Architecture, Learning, Event-Driven, Go — Mentions component tests in the context of testing across architecture layers, noting their role in verifying service behavior without calling external services.
