E2E vs Unit vs Integration Testing

Unit Testing

A unit test validates the smallest testable piece of code, typically a single function or method, in complete isolation from the rest of the application. The test provides inputs, calls the function, and asserts that the output matches the expected result. External dependencies like databases, APIs, and file systems are replaced with mocks or stubs so the test focuses exclusively on the logic inside the function.

Unit tests are the fastest type of automated test. A single unit test runs in milliseconds because it does not launch a browser, start a server, or make network calls. A project with thousands of unit tests can execute its entire suite in seconds, which makes them ideal for rapid feedback during development. Every time a developer saves a file, the relevant unit tests can run instantly and report whether the change broke any existing logic.

The primary limitation of unit tests is that they cannot detect problems that arise from the interaction between components. A function might produce the correct output in isolation but fail when its output is consumed by another function that expects a different format, when the database schema changes, or when a configuration value in production differs from the test environment. Unit tests verify correctness at the component level but say nothing about whether the components work together.

Typical targets for unit testing include utility functions, data transformation logic, business rule calculations, input validation, and state management reducers. These are areas where the logic is self-contained and the inputs and outputs are well-defined. Functions that primarily coordinate between other components (calling an API and writing the response to a database) are better covered by integration tests.

Integration Testing

Integration tests verify that two or more components work together correctly. The scope is broader than a unit test but narrower than an E2E test. An integration test might verify that a service layer correctly queries the database and formats the response, that an API endpoint accepts a request and returns the right status code with the correct response body, or that a React component renders the right output when given data from a custom hook.

Integration tests use real implementations of some dependencies while mocking others. For example, an API endpoint test might use a real database (or an in-memory equivalent like SQLite) but mock the email service and payment gateway. This approach catches bugs in the interaction between the endpoint logic and the database queries without requiring external services to be available.

Speed falls between unit and E2E tests. An integration test that queries a real database might take 50 to 500 milliseconds, compared to 1 millisecond for a unit test and 5 to 30 seconds for an E2E test. This intermediate speed makes integration tests practical for running on every commit while still testing meaningful interactions.

Integration tests catch a category of bugs that neither unit nor E2E tests detect efficiently. A common example is a mismatch between the API contract and the front-end expectations. The API might return { "userName": "Alice" } while the front end expects { "username": "Alice" }. A unit test for the API and a unit test for the front-end component would both pass, but an integration test that connects them would catch the casing difference immediately.

The testing trophy model, popularized by Kent C. Dodds, argues that integration tests provide the best return on investment because they catch the most realistic bugs per line of test code. Integration tests verify actual behavior rather than implementation details, which means they are less likely to break during refactoring than unit tests that test internal function calls.

End-to-End Testing

End-to-end tests exercise the complete application stack by driving a real browser through user workflows. The test opens a browser, navigates to the application, interacts with page elements, and asserts that the visible result is correct. Every layer of the application participates: the front-end rendering, the API server, the database, authentication, session management, and any third-party services.

The defining advantage of E2E tests is confidence. When an E2E test passes, you know that the entire chain works for that specific user flow. No amount of unit and integration tests can provide the same guarantee because they test components in controlled environments that may differ from the real deployment.

E2E tests are the slowest and most expensive to run. Each test launches a browser instance, makes real network requests, and waits for page renders and API responses. A single test might take 5 to 30 seconds, and a suite of 200 tests could take 15 to 60 minutes if run sequentially. Parallel execution reduces this dramatically, but E2E suites still consume more CI resources than unit or integration tests.

Flakiness is the most common criticism of E2E testing. Because E2E tests depend on multiple moving parts (browser rendering, network latency, database state, background processes), they are more susceptible to intermittent failures than tests that control their environment completely. Modern frameworks like Playwright have significantly reduced flakiness through auto-waiting, retry mechanisms, and deterministic browser control, but maintaining a flake-free E2E suite still requires ongoing discipline.

Side-by-Side Comparison

The three test types differ across several dimensions. In terms of speed, unit tests run in milliseconds, integration tests in hundreds of milliseconds, and E2E tests in seconds. For scope, unit tests cover one function, integration tests cover a module boundary, and E2E tests cover an entire user flow. Regarding confidence, unit tests confirm that individual logic is correct, integration tests confirm that modules communicate properly, and E2E tests confirm that the application works for the user.

Maintenance cost follows a similar gradient. Unit tests are cheap to maintain because they are small and isolated. Integration tests require more setup (database schemas, API mocks) but are still manageable. E2E tests are the most expensive because they interact with the UI, which changes frequently, and depend on environment stability.

Bug detection patterns also differ. Unit tests catch logic errors in algorithms and calculations. Integration tests catch contract mismatches, serialization problems, and database query errors. E2E tests catch UI rendering bugs, cross-component communication failures, and workflow-level regressions that only manifest when a user completes a multi-step process.

Building a Balanced Testing Strategy

The testing pyramid recommends a broad base of unit tests, a middle layer of integration tests, and a narrow top of E2E tests. The exact ratio depends on your application's architecture and risk profile, but a common starting point for a web application is roughly 70% unit tests, 20% integration tests, and 10% E2E tests by count.

The pyramid shape is not about the absolute number of tests but about the distribution of coverage. If your application is primarily a CRUD interface with little business logic, you might invert the pyramid and write more integration and E2E tests because the interesting bugs occur at the boundaries, not inside individual functions. If your application has complex algorithms (financial calculations, data processing pipelines), unit tests become more important because the logic density is higher.

A practical approach is to start from both ends. Write unit tests for every function that contains business logic worth verifying. Write E2E tests for the 10 to 20 most critical user flows. Then fill in the middle with integration tests for API endpoints, database queries, and component interactions. This approach ensures immediate protection for the highest-risk areas while building comprehensive coverage over time.

Avoid duplicating coverage across test types. If an E2E test already verifies that a user can log in, you do not need a separate integration test for the login API endpoint and a unit test for the password hash comparison function. The E2E test covers all three layers. Focus lower-level tests on edge cases and error handling that E2E tests do not reach: password validation rules, rate limiting logic, error message formatting, and boundary conditions.