A login flow can pass its unit tests yet fail after deployment because configuration is missing, a secret is wrong, a database is unavailable, or another service responds unexpectedly. An integration test checks those real connection points: it assesses how components or services behave together rather than in isolation. section 2.1.2 section 12.1
Integration tests sit between unit tests and end-to-end tests in the test automation pyramid. Unit tests use mocked dependencies and run in isolation; integration tests verify actual dependencies; end-to-end tests cover the full user experience. Because higher-level tests are slower and more expensive, a balanced suite favors many unit tests, fewer integration tests, and still fewer end-to-end tests. section 2.1 section 12.2
Use integration tests for behavior that requires the integrated environment, especially:
- Checking that build configuration, infrastructure configuration, and secrets reach a deployed application correctly. section 12.1
- Verifying database and infrastructure behavior alongside request and response handling. section 12.1
- Asserting the actual returned data after required database data has been set up. section 12.2
- Testing system-dependent cases such as a login service slowed by incoming requests. section 2.2
API-focused integration tests commonly assert response headers, status codes, and bodies against a running service. A movies endpoint test, for example, can send GET /movies and expect JSON, HTTP 200, and an empty response array. These checks validate the service as integrated, but their stability can depend on environment availability and correctly prepared data. section 12.3 section 12.2
Testing a movies API
Run the Express movies server, call its GET /movies endpoint through Supertest, then assert its Content-Type header, 200 status, and response body. This verifies a real server dependency rather than a mocked unit boundary; it can also reveal failures caused by environment state. section 12.3 section 12.2
Contract testing can move some API checks earlier by verifying shared expectations for data structures, HTTP status codes, headers, and API versions through consumer-provider contracts. It does not replace integration testing: contract tests operate at a service boundary, while integration tests remain necessary for deployment, infrastructure, database, and configuration problems. section 12.2 section 12.5
Figure 12.2 Contract and integration test responsibility boundary, showing how integration tests check for infrastructure and database problems as well as request and response errors
Compare the responsibility boundary: contract tests cover service-interface expectations, while integration tests extend into infrastructure and database behavior. section 12.1
When a legacy integration test only checks API structure rather than specific returned values, consider converting it to a contract test for earlier, more stable feedback. Retain integration coverage for conditions that only emerge after deployment into a shared environment; replacing every integration test would leave those risks untested. section 12.5 section 12.0
