2 posts tagged with "Integration Tests"

TL;DR: Boot the full Spring context. Stub only what lives outside your service boundary: Feign clients, external HTTP APIs, outbound Kafka. Then hit the service through its real HTTP endpoint and verify the entire chain: controller, validation, service logic, @Transactional, repository, database write, response serialization. This is what Spring calls an integration test. It catches the class of bugs that unit tests structurally miss: broken configs, silent serialization changes, transaction proxy bypass, security filter misconfiguration, and DTO contract drift.

TL;DR: In real-world Spring projects, the "unit vs integration" debate almost always stems from the fact that "integration testing" has become a catch-all term for everything from @SpringBootTest with Testcontainers to full-blown E2E runs on staging environments. To stop arguing and start shipping, we need to draw a clear line in the sand regarding responsibility.

A unit test answers one question: "Is the logic correct in total isolation?" It deliberately cuts infrastructure out of the equation.

A component test answers another: "Does the component work as a system within its own boundaries, including its Spring wiring, configurations, serialization, transactions, and data access?"

If you only have units, you'll inevitably get burned at the seams. If you only have component tests, you'll pay with execution time, flakiness, and painful debugging. The winning strategy is simple: unit tests provide the speed and density of logic verification; component tests provide the confidence that the "real assembly" actually works.