Integration Testing

Integration testing checks whether multiple software parts cooperate across a boundary. A test starts a system under test, connects it to one or more collaborators, triggers behavior through a real entry point, and observes the result. The boundary might be a database driver, an HTTP API, a message broker, a file system, or framework wiring.

That scope distinguishes an integration test from a unit test. A unit test isolates a small piece of logic and commonly replaces infrastructure with a test double. An integration test keeps the boundary under examination real enough to expose mismatched schemas, serialization errors, configuration mistakes, and incorrect assumptions about another component. It is usually slower and more expensive to diagnose because more moving parts participate.

Integration testing is also narrower than end-to-end testing. An end-to-end test follows a complete user or business flow through the deployed system. A focused integration test can exercise one application boundary without a browser, production network, or every downstream service. Teams use both scopes, but each test should state which boundary it proves.

The test path

A useful integration test has five parts:

System under test: the application, service, repository, or component whose behavior is being checked.
Entry point: a public API, command, event, or method that triggers the behavior.
Collaborator: a real dependency, controlled emulator, or test double on the other side of the selected boundary.
Fixture: the configuration and data required to create a known starting state.
Observation: an externally visible result, such as a response, stored record, published message, or file.

Integration Testing

The test path

Relevant careers