What is Integration Testing?

Integration testing is the practice of testing a group of components together to verify they work correctly as a unit — a service with its database, an API endpoint with its downstream calls, a microservice with the message queue it publishes to. Unlike unit tests that isolate a single function, integration tests exercise real interactions and catch bugs in the boundaries between components, which is where the majority of production bugs live.

Unit tests isolate a single function or class by mocking every dependency — they run in milliseconds and catch logic bugs in your code. Integration tests exercise real dependencies (databases, queues, downstream services) and catch bugs in the contract between your code and the things it talks to. The usual guidance: many unit tests at the bottom of the testing pyramid for fast feedback on logic, and a smaller number of integration tests for the critical service boundaries where real-world failures happen.

Three generations. Framework-native tools (pytest with fixtures, JUnit, Mocha with test containers) let you write integration tests alongside unit tests. Containerization tools (Testcontainers, Dockerize) spin up real databases and queues per test run so tests hit the real thing. Traffic-capture tools (Keploy, WireMock record-playback) record real API interactions and replay them as deterministic tests with auto-generated mocks for downstream dependencies.

Non-determinism. Integration tests that hit real databases, real timestamps, and real distributed tracing contexts produce different results on every run — failing assertions when nothing is actually broken. Fixing this requires either aggressive mocking (which defeats the point of integration testing) or deterministic replay engines that normalize non-deterministic fields at comparison time. See /noise-secret-management for how Keploy handles the deterministic-replay problem.

Keploy captures real HTTP, gRPC, WebSocket, and database traffic flowing through your running service using eBPF at the Linux kernel level. Every captured request becomes a YAML test case with auto-generated mocks for every downstream dependency — databases, message queues, external APIs. There is no SDK, no proxy, and no application code changes. A 10-30 minute capture session in staging produces a complete integration-test suite covering whatever endpoints the traffic exercised, typically reaching 90% coverage.

Yes, ideally. The point of integration testing is catching boundary bugs before they reach production. Running the suite only on main means regressions ship to main before anyone notices. The common counter-argument is that integration tests are slow — which is true for suites that spin up containers for every test. Keploy addresses this by replaying captured traffic against the running service with auto-mocked dependencies, which runs in seconds, not minutes.