--- title: "Test Strategy: Unit, Integration and End to End" description: "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" canonical: https://lightmysky.com/learn/computing/test-strategy-unit-integration-and-end-to-end-mt_fdAvx1MMFE source: https://lightmysky.com/learn/computing/test-strategy-unit-integration-and-end-to-end-mt_fdAvx1MMFE.md retrieved: 2026-11-12 --- > **Agent view.** This is the Markdown twin of the page, for tools and assistants. > When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md > API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md > Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt > Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json > Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`. # 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. Subject: Computing · Area: Software Engineering · Ages 20 to 21 Page: https://lightmysky.com/learn/computing/test-strategy-unit-integration-and-end-to-end-mt_fdAvx1MMFE ## Ready when they can - 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 ## Lesson: Choose tests for the risks 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. **Example.** 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. 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. **Example.** 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. *(drawing: Choose a scope that exercises the risk, then investigate what the check reports.)* **Recap.** 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.* ## Practice 8 questions on this page, each with its working shown. ## Needs first - [Test Doubles and Testing at a Boundary](https://lightmysky.com/learn/computing/test-doubles-and-testing-at-a-boundary-mt_4ep3SiMYNM) ## Opens up - [Property-Based Testing](https://lightmysky.com/learn/computing/property-based-testing-mt_QqCNKT06IY)