Don't Panic — Integration Testing

Integration testing is the part of testing where software components stop being polite diagrams and start exchanging real data across a boundary. One part of the application calls another system, such as a database, HTTP service, message broker, file system, or framework host. The test asks whether that collaboration produces the result the application claims it will. A unit test can prove the calculation. It cannot tell you that the database driver, schema, transaction, and application agreed on what an order was supposed to become.

The useful shape has five pieces: a system under test, meaning the component whose behavior matters; an entry point that triggers it; a collaborator on the far side of the boundary; a fixture that makes the starting state known; and an observation that catches the result in the act. Setup, trigger, observe, clean up. This is less glamorous than it sounds, which is fortunate, because reliable tests usually are.

The surprise is that “integration” does not mean “start every service and hope for the best.” A narrow test can connect one repository to one database. A broad test can start several services. The name should state the boundary, because every extra real collaborator also creates another possible explanation when the run fails. A real local service preserves behavior that an in-memory substitute cannot, while a test double can make rare errors repeatable. Neither is magic; each proves only the behavior it contains.

Determinism means the same controlled inputs and state produce the same result. Give tests unique identifiers. Reset mutations. Keep parallel workers out of the same database, queue, port, namespace, or tenant. A process with an open port is not necessarily ready for useful work, which is a small but persistent betrayal by computers. Wait for the operation you need: a query, a health response, or a test message, with a deadline.

Assertions should watch the external result. If an HTTP request creates an order, inspect the response and the stored order. Count internal calls only when that interaction is itself the contract. If a run fails after another test, suspect leaked state. If it fails only in parallel, suspect a resource collision. If it passes on retry, preserve the first failure rather than declaring the universe stable again.

Read the intro for the fuller map of scopes, fidelity, fixtures, and failure diagnosis. The slides compress the choices into paths and decision rules. The cheatsheet is the working reference when selecting collaborators, reset strategies, and observations. The practice reference and exercise turn the pattern into one controlled HTTP-to-database test. The quiz checks whether the boundaries have stayed in the correct boxes.

Don't Panic — Integration Testing

Relevant careers