An integration test checks that two or more parts of a system work together at one boundary, such as a service and its database or a client and an API. An end-to-end (E2E) test checks a complete user journey through the running application, from the browser to the backend and back. Use integration tests for most of the logic and reserve E2E tests for the few journeys that must never break.
The difference is the boundary, not the tool
Both kinds of test exercise more than one unit of code. What separates them is where the test starts and stops.
- Integration test: starts at a code or network boundary inside the system. It calls an application programming interface (API) endpoint and checks the database, or calls a service with a real queue behind it. Parts outside that boundary are real or replaced with stand-ins, by choice.
- End-to-end test: starts where the user starts, usually a browser, and ends at what the user sees. Everything in between is the real deployed system.
The same framework can write both. A browser automation tool can call an API directly, and an API test client can drive a whole journey. Classify a test by what it covers, not by the library it imports.
Integration tests fail close to the cause
An integration test fails close to the cause. When a query returns the wrong rows, the test that calls the repository and checks the rows points at the query. The same bug caught by an E2E test shows up as a missing line on a page, several layers away from the cause.
Integration tests are also cheaper to keep. They have fewer moving parts, they usually run faster, and they do not depend on page layout. A change to a button label does not touch them.
That makes them the right place for most combination logic: validation rules, permissions, data transformations, error handling between services. Write many of them.
E2E tests prove the journey works
What integration tests cannot show is that the pieces add up for a user. Each boundary can pass its own test while the journey fails: a front end that calls the wrong endpoint, a redirect that loses a session, a configuration that exists in one environment and not the next. Only a test that walks the whole path catches these.
E2E tests also run in real browsers. Playwright, for example, can run tests on Chromium, WebKit and Firefox as well as branded browsers such as Google Chrome and Microsoft Edge [Microsoft (Playwright)]. Browser differences are invisible to integration tests.
So write E2E tests for the journeys that must work in every release: sign up, sign in, the core action of the product, payment. Keep the list short. How many E2E tests you need goes through how to choose them.
Wider tests have more ways to be flaky
Flakiness is common across test types. Almost 16% of Google's tests have some level of flakiness [Google Testing Blog]. In a study of flaky test fixes, the top three categories were Async Wait, Concurrency and Test Order Dependency [University of Illinois at Urbana-Champaign / ACM FSE].
An E2E test crosses more asynchronous boundaries than an integration test: network calls, rendering, animations, background jobs. Each one is a place for an Async Wait problem. Modern frameworks help. Playwright performs actionability checks on elements before acting, auto-waits for them to pass, and fails with a timeout error if they do not [Microsoft (Playwright)]. Waiting still has to be on the right condition, and the more boundaries a test crosses, the more conditions there are to get right. E2E test maintenance cost covers what that costs over time.
Put each check at the lowest level that can catch it
A simple rule settles most debates: test each behaviour at the lowest level that can catch its failure.
- A calculation or a rule: unit test.
- Two services or a service and its store: integration test.
- A journey a user takes through several screens: E2E test.
When an E2E test fails and the cause turns out to be a rule inside one service, add an integration test for that rule. Then check whether the E2E test still adds anything. Often it does, because it guards the journey. Sometimes it can be removed.
How AI Testing Platform fits
AI Testing Platform runs E2E tests written as plain-English steps, and each step is resolved against the live page at run time (plain-English tests, spec format). API steps are in beta: a step can call a web endpoint and assert on the response in the same test as user interface steps, which puts a boundary check inside a journey (API steps). The platform runs the tests that were written; it does not replace a layer of integration tests or prove that an application has no bugs (what we cannot do).