What is the difference between unit testing, integration testing, and end-to-end testing in a Python application?
Unit isolates one component, integration tests interactions, end-to-end tests the whole system
The three levels differ in scope and in what they allow to be real. A unit test exercises a single function or class in isolation, with every external dependency replaced by a fake, so a failure points at one piece of logic. An integration test exercises several real components together, such as your repository against a real database, so it catches contract mismatches that unit tests cannot see. An end-to-end test drives the system through its real entry point, typically HTTP or the CLI, against a deployed or fully wired environment, so it validates that the whole thing works from the user's perspective. The test pyramid is the guiding heuristic: many fast unit tests, fewer integration tests, and a small number of slow end-to-end tests. The reason is not dogma but cost: unit tests run in milliseconds and pinpoint failures, while end-to-end tests are slow, flaky, and expensive to debug.
- 1
Unit: pure function or class under test, all collaborators mocked or faked, deterministic, fast, no IO.
- 2
Integration: real database, real message broker, or real filesystem, but typically not the whole service. Verifies contracts and configuration.
- 3
End-to-end: real deployment or a full local stack, real HTTP, real auth. Verifies the user-visible path and deployment wiring.
- 4
Trade-off: the more real the environment, the higher the confidence but the slower and more brittle the test. Push verification down the pyramid whenever possible.
- 5
Common mistake: writing only unit tests with everything mocked, which passes even when the real database schema does not match.
- 6
Common mistake: calling a test an integration test because it starts a server, when it actually mocks the database and the message broker. That is still effectively a unit test with overhead.
- 7
Version note: the pyramid is a heuristic, not a standard. Some teams use test trophies or honeycomb models depending on their risk profile.
Scenario Questions
0-2 years experience
- 1A function calls a database. Which test level would exercise it without a real database?
- 2Why are end-to-end tests slower than unit tests?
2-5 years experience
- 1A bug ships because the tests mocked the ORM but the real query was wrong. What test level would have caught it?
- 2You have 3000 unit tests and a 20-minute end-to-end suite. How do you rebalance the pyramid?
5-8 years experience
- 1Your integration tests share a database and become flaky under parallelism. How do you isolate them per test?
- 2You need to verify a payment flow without calling the real provider. Where do you draw the boundary between integration and end-to-end?
8+ years experience
- 1Design a test strategy for a microservice platform with shared contracts, including contract tests, ephemeral environments, and failure injection.
- 2Explain how to keep end-to-end suites reliable and fast at scale, including data seeding, parallelism, and flakiness quarantine.
Follow-up Questions
- How would you decide whether a bug should be covered by a unit test or an integration test?
- What signals tell you your end-to-end suite has become too large?