Unit vs Integration vs End-to-End Testing Explained

Every team that ships software eventually hits the same wall: a bug reaches production even though “we have tests.” Usually the problem isn’t the number of tests. The tests are checking the wrong things at the wrong level. A pile of slow browser tests that break every week is as unhelpful as a thousand unit tests that never touch the database.

This guide explains the 3 main test types, what each should and shouldn’t cover, and how to balance them so your suite catches real bugs without slowing every release.

The short version

Key takeaway: Push each check down to the lowest level that can catch it. Use end-to-end tests only for the handful of journeys your business can’t afford to break.

Unit tests: fast checks on small pieces

A unit test calls one piece of code with known inputs and checks the output. The “unit” is usually a function, a class or a single UI component. Anything slow or unpredictable, like a database, network call or the system clock, is replaced with a fake.

Here is a simple example in JavaScript using Jest or Vitest:

```javascript // discount.js export function applyDiscount(total, code) { if (code === “SAVE10”) return Math.round(total * 0.9 * 100) / 100; return total; }

// discount.test.js import { applyDiscount } from “./discount”;

test(“SAVE10 takes 10% off”, () => { expect(applyDiscount(50, “SAVE10”)).toBe(45); });

test(“unknown codes change nothing”, () => { expect(applyDiscount(50, “BOGUS”)).toBe(50); }); ```

What unit tests should cover:

• Business rules: pricing, tax, discounts, eligibility, permissions logic
• Edge cases: empty lists, zero, negative numbers, very long strings, time zones
• Error handling: what happens with bad input
• Pure UI logic: a component shows the right label for each state

What they shouldn’t try to cover: whether your SQL query actually works, whether the payment provider accepts your request, or whether the login page loads in Safari. Mocking those in a unit test proves only that your mock behaves the way you told it to.

Unit tests are cheap enough to run on every save. That fast feedback is their main value, so keep them fast. If a “unit” test takes seconds, it’s probably doing integration work.

Integration tests: checking the connections

An integration test checks that 2 or more parts work together for real. Common examples:

• Your repository code against a real database (often started in a container for the test run)
• An HTTP endpoint, tested through your web framework, including routing, validation and serialization
• A message published to a queue and picked up by the consumer
• Your code calling a third-party API’s sandbox, or a contract test against its published schema

Here is the kind of thing an API integration test checks in plain terms: “POST /orders with a valid body returns 201, writes 1 row to the orders table and the row has the right total.” No browser is involved, but the real framework and database are.

What integration tests should cover:

• Database queries, migrations and transactions
• Serialization: dates, decimals, nulls and enums surviving the trip in and out
• Authentication middleware actually blocking anonymous requests
• Contracts between your services, which matters a lot once you move from a monolith to microservices

The trade-off: integration tests are slower and need setup, such as seeded data and cleanup between tests. In the widely cited Practical Test Pyramid article on martinfowler.com, Ham Vocke also warns that tests against a fake version of an external service can pass while the real service has changed. That is why contract tests, which check that a provider and its consumers agree on the interface, sit alongside integration tests in many teams.

End-to-end tests: the user’s point of view

An end-to-end test drives the whole system the way a user does. For a web app, that usually means a browser automation tool clicking through pages against a deployed test environment. Playwright’s documentation, for example, lists support for Chromium, WebKit and Firefox on Windows, Linux and macOS, and runs tests in parallel by default.

A typical E2E test reads like a user story: open the store, search for a product, add it to the cart, check out with a test card, and confirm the order page shows a number.

What E2E tests should cover:

• The few journeys that make or lose money: sign up, log in, checkout, password reset
• Cross-system flows nobody owns end to end, like order to email to fulfillment
• Smoke tests after each deployment: “the app loads and a user can log in”

What they shouldn’t cover: every validation message, every discount rule or every permutation of a form. Those belong lower down. The Practical Test Pyramid article calls end-to-end tests notoriously flaky and expensive to maintain, and recommends keeping them to the most important user journeys.

Flakiness is the real cost. When an E2E test fails because a page loaded 200 milliseconds late, people learn to rerun and ignore failures. Then a real failure slips through.

The test pyramid and how to use it

The test pyramid, introduced by Mike Cohn in his book Succeeding with Agile, is a simple picture: a wide base of unit tests, a middle layer of integration or service tests and a narrow top of end-to-end tests. The higher you go, the fewer tests you should have.

A 2015 Google Testing Blog post offered roughly 70% unit, 20% integration and 10% end-to-end as a starting point, while noting the right mix varies by team. Treat that as a rule of thumb, not a target to hit.

The shape to avoid is the “ice cream cone”: a thin layer of unit tests, some integration tests and a huge stack of manual and browser tests on top. It feels thorough but runs slowly, fails randomly and gives vague error messages.

Some front-end teams prefer a “testing trophy” shape that puts more weight on integration-style component tests, because modern UI frameworks make those tests fast. That’s a reasonable variation. The principle stays the same: most of your confidence should come from tests that are fast and precise.

What each layer looks like for 1 feature

Take a “coupon code at checkout” feature:

Notice that the E2E test doesn’t retest every rule. It proves the pieces are wired together.

Common mistakes that waste test effort

• Mocking everything. If every dependency is mocked, your tests pass while production breaks. Use real dependencies in integration tests.
• Testing implementation details. Tests that check private methods or exact HTML structure break on every refactor. Test behavior and outputs instead.
• Duplicating checks across layers. If a unit test already proves a rule, the E2E test doesn’t need to.
• Ignoring flaky tests. Quarantine and fix them quickly. A suite people don’t trust is a suite people skip.
• Chasing a coverage number. Coverage shows what code ran, not whether the assertions were meaningful. Use it to find untested areas, not as a grade.
• Running everything at the end. Slow suites that run only before release push bug discovery late, which is a classic source of technical debt.

Where to start: building a balanced suite

If your project has few tests, or the wrong mix, use these steps:

1. List your critical journeys. Pick the 3 to 10 flows that would cost money or trust if they broke. Those are your E2E candidates.
2. Add a smoke test first. One E2E test that loads the app and logs in catches a surprising number of broken deployments.
3. Cover business rules with unit tests. Start with the code that changes often or has caused bugs before.
4. Add integration tests at each boundary. Database, external APIs and service-to-service calls each get a few focused tests.
5. Run tests in your pipeline. Unit tests on every commit, integration tests on every pull request, E2E tests before or right after each deployment. Our guide to building a CI/CD pipeline shows where each stage fits.
6. When a bug escapes, write the lowest-level test that would have caught it. Over time this shapes the pyramid naturally.
7. Review slow and flaky tests monthly. Delete or push down any high-level test that a lower-level test already covers.

Static type checking adds another cheap safety layer below unit tests. If you work in JavaScript, see TypeScript vs JavaScript for what types catch before a test even runs. And before a big release, pair your automated suite with a pre-launch QA checklist.

Conclusion

Unit, integration and end-to-end tests aren’t competitors. They answer different questions. Unit tests ask “is this logic right?”, integration tests ask “do these parts talk to each other correctly?” and end-to-end tests ask “can a user actually do the thing?” Write many of the first, a solid layer of the second and just enough of the third. Your suite will run faster, fail for real reasons and tell you exactly where to look. For more on how testing fits into delivery, read what CI/CD is or browse the glossary.

Sources

• The Practical Test Pyramid, martinfowler.com (Ham Vocke, 2018) — test pyramid origin with Mike Cohn, layer guidance, flaky E2E tests, contract tests
• Just Say No to More End-to-End Tests, Google Testing Blog (2015) — 70/20/10 starting split and E2E feedback-loop drawbacks
• Playwright documentation: Installation — supported browsers, platforms and default parallel runs