---
title: "Test Strategy: Unit, Integration and End to End"
description: "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 ma"
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-09-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

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.

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 why a suite of only end-to-end tests slows a team down
- Say what an integration test proves that a unit test cannot

## Lesson: Small fast tests, a few big ones

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.

**Example.** 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.

**Tip.** 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.

**Recap.** Use many fast unit tests, some integration tests for combined parts, and a few end-to-end tests for the whole journey.

## 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)