Test Strategy: Unit, Integration and End to End
A test strategy assigns risks to checks with suitable scope, speed and realism. Isolated tests check local logic, integration tests exercise selected real interactions, and end-to-end tests exercise a complete journey. None proves the whole system correct.
What a learner can do afterwards
- Assign a set of risks to the level of test that should catch each one
- Explain how an end-to-end-only suite can delay feedback and make failures harder to locate
- Explain what testing selected real interactions checks beyond isolated tests using doubles
1 · Read
Teams use test-level names differently. Here, a unit test checks a small piece of logic in isolation from external services. It is often fast and helps locate faults in that logic. As in earlier lessons, a passing test establishes its observations, not correctness for every input.
An end-to-end test exercises a complete user journey through the assembled application, such as choosing a book, checking out and receiving a receipt. It checks that tested journey under its test conditions. It does not prove every journey works. Its broad scope can make setup and failure diagnosis more expensive.
An integration check can send a request through the application adapter to the provider's actual test endpoint and observe its response. An isolated check instead substitutes a double's chosen response. The isolated check does not exercise that endpoint exchange, even when its chosen response matches what the endpoint would return.
This route exercises the endpoint. A substituted response does not.
To check a payment adapter against a provider, use the provider's test environment and test credentials. Do not charge live customers for a test. A focused integration check can reveal incompatible request or response formats. A journey test may also encounter the failure, but it is not the only useful level.
End-to-end tests are not inherently flaky. Flakiness means inconsistent pass or fail results without a relevant code change. More components and shared environments can introduce that risk. If every arithmetic check goes through a slow browser journey, feedback may be delayed and failures may be harder to locate.
Check a totals function directly: choose inputs, call it and compare its result with an independent expected total. A browser or payment provider is unnecessary for this calculation. Keep a journey check for whether the application displays the total in the right place.
A failure involving several components does not automatically require a whole journey test. An integration test can run the real discount, refund and receipt components together without using a browser. Choose the smallest scope that exercises the suspected interaction, then retain journey checks for journey-level risks.
Choose test counts from risks, not a fixed quota. Put detailed local checks at a focused level where practical. Add integration checks for real boundaries and combinations, and journey checks for complete workflows. Measure runtime and investigate flaky checks rather than accepting them as unavoidable.
Match each risk to a suitable test scope. Check local logic, selected real interactions and complete journeys without treating any passing suite as proof.
Original lesson, questions and flashcards written for this learning dataset.
2 · Watch
En anglaisTake 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.