We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Devops Cicd
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
Every unit test was green. The UserService correctly validated input. The DatabaseRepository correctly constructed queries. The EmailService correctly formatted messages. But when UserService called DatabaseRepository, the query returned data in a different format than expected. And when EmailService received that data, it crashed on a null field that the mock had never returned.
Every component worked in isolation. The system was broken at the seams.
This is the fundamental gap that integration tests fill. Unit tests mock external dependencies and verify internal logic. Integration tests wire real components together and verify they actually communicate correctly. The database driver connects. The API returns the expected schema. The delivers messages in the format the consumer expects.
Martin Fowler calls this the "integration test scam" when teams claim high test coverage from unit tests alone. A test suite with 95% unit test coverage and zero integration tests gives false confidence. The 5% it misses is often the wiring between components, which is where the highest-impact bugs live.
Integration tests cover boundaries between components. If two pieces of code are in the same process and share the same data structures, that is a unit test. If they communicate over a network, a driver, or a serialization format, that is an integration test.
| Boundary | What Can Go Wrong | Integration Test |
|---|---|---|
| Database queries | ORM generates unexpected , schema drift | Run queries against real Postgres |
| API contracts | Producer changes response shape without telling consumers | Verify actual response structure |
| Message serialization | Producer writes JSON, consumer expects Avro | Produce then consume a message |
| File I/O | Permissions, paths, encoding (UTF-8 vs Latin-1) | Read and write actual files |
| Cache behavior | , eviction, serialization format | GET/SET against real |
| External APIs | Third-party changes response without warning | Test against sandbox or record-replay |
Testcontainers is the modern standard for integration testing. It spins up real databases, message queues, and services in containers scoped to each test run. After the tests complete, containers are destroyed. No shared state between test runs, no need to maintain a dedicated test database.
Testcontainers was originally a Java library (2015) and now supports Node.js, Python, Go, Rust, and .NET. Spotify, Netflix, and Confluent use it extensively in their CI pipelines.
It is easy and good
“It is really nice and good Please join the course”