Integration Testing: Do Your Components Play Well Together?

WHY IT EXISTS: Individual components can pass all their unit tests but still fail when combined. This happens because of incorrect assumptions about how other components behave, like data formats, API contracts, or network latency. Integration testing exists to find these critical 'interface' bugs before they reach users.

THE MENTAL MODEL: Think of building a car from pre-tested parts. A unit test confirms the engine runs perfectly on a stand. An integration test bolts the engine to the transmission and verifies they work together without grinding gears. It's not about testing the whole car driving on a road (that's an end-to-end test), but about checking that key sub-systems are correctly assembled.

HOW IT WORKS: Integration tests combine two or more components of your application and test them as a group. For example, a test might make a real HTTP request to your API endpoint, which then interacts with a real (or test-double) database. The test asserts that the data was correctly created or retrieved, verifying the entire flow between those specific components. Unlike unit tests that heavily mock dependencies, integration tests use real implementations where possible to test the 'seams' between them.

WHEN TO USE IT: Use integration tests for critical application workflows where multiple services interact. Three key places are: first, user authentication flows (web server to auth service to database); second, payment processing (API to payment gateway); third, data pipelines (one service producing data, another consuming it). They are a key part of a CI/CD pipeline, often run after faster unit tests pass.

WHEN NOT TO USE IT: Avoid using integration tests to check simple business logic within a single component; that's a job for faster unit tests. Also, don't use them to test every single permutation of user interaction through the UI; that's better suited for end-to-end (E2E) tests. Because they are slower and more complex than unit tests, running too many can drastically slow down your build pipeline.

ONE CANONICAL EXAMPLE: A classic integration test for an e-commerce site would be for the 'Add to Cart' feature. The test would make an API call to add an item to a cart. It would then verify that the API service correctly communicates with the database service to create a new record in the cart_items table. The test confirms the API and database are integrated correctly, without involving the UI or other unrelated services.