Test Strategy: Unit, Integration and End to End
Tests trade speed against realism. Many small tests find faults fast and prove little about the assembled system; a few whole-system tests prove a lot and are slow and flaky. A strategy decides how many of each and what each level is responsible for.
What a learner can do afterwards
- Assign a set of risks to the level of test that should catch each one
- Explain why a suite of only end-to-end tests slows a team down
- Say what an integration test proves that a unit test cannot
1 · Read
You already met stand-ins for slow neighbours. Now zoom out. Small unit tests run in milliseconds and find faults fast, but they prove little about the assembled system. Whole-system end-to-end tests prove a lot, but they are slow and flaky.
Integration tests sit between the two. They prove that combined parts work together, such as your code plus the real payment service. That is the thing a unit test with stand-ins can never prove.
For a checkout page you write many unit tests for prices and totals, a few integration tests for charging through the payment service, and one end-to-end test that buys a book from click to receipt. Each level owns different failures.
A suite of only end-to-end tests slows a team down. Every small change waits for the slow suite, flakes block merges, and nobody knows which part failed. Keep the slow tests few and push detail down to faster levels.
Use many fast unit tests, some integration tests for combined parts, and a few end-to-end tests for the whole journey.
2 · Watch
Take it off screen
Where it sits
Learn first
This opens up
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.