End-to-End Tests and Where to Use Them

E2E tests are a type of software testing that focuses on verifying the functionality and behavior of an entire application from the user's perspective. Unlike unit tests and integration tests, which isolate specific components or units of code, E2E tests simulate real user interactions and test the application as a whole. Here are some key characteristics and aspects of end-to-end tests:

• Scope: E2E tests cover the entire application, including the user interfaces, backend services, databases, and any external dependencies. They aim to validate that the entire system functions correctly and delivers the expected user experience.

• User scenarios: E2E tests are designed to mimic real user scenarios, such as interacting with the application’s UI, submitting forms, navigating between pages, and interacting with different features. These tests follow user paths through the application.

• Real user inputs: E2E tests use real user inputs and interactions, such as clicking buttons, typing into text fields, and navigating menus. They also involve simulating user actions like mouse clicks and keyboard inputs.

• Realistic data: E2E tests often use realistic test data that closely resembles what real users would input or encounter during their interactions with the application.

• E2E flows: E2E tests typically cover entire E2E flows, which involve multiple steps and interactions within the application. For example, they can test the process of signing up, logging in, and making a purchase using an e-commerce application.

• UI and UI interactions: E2E tests interact with the application’s user interface, validating that the UI elements are displayed correctly, that the navigation works as expected, and that user actions trigger the correct responses.

• External services: E2E tests involve external services—such as payment gateways, APIs, or third-party integrations—to ensure that the application’s interactions with these services function correctly.

• Slow execution: E2E tests tend to be slower than unit and integration tests because they involve real interactions with the application, and there may be wait times for UI elements to load or for actions to complete.

• Browser or application context: E2E tests are often executed in the context of a web browser or the application’s UI, depending on the nature of the software being tested. Tools like Selenium and Cypress are commonly used for web-based E2E testing.

• Test environments: E2E tests may require dedicated test environments that closely resemble the production environment, including database configurations, external integrations, and network settings.

• Regression testing: E2E tests are valuable for regression testing because they ensure that new code changes or updates do not break the existing functionality or user workflows.

• User experience validation: E2E tests help validate that the application delivers the intended user experience and that all the features and functionalities work as expected.

E2E tests provide a high level of confidence in the overall functionality and usability of the application, but they also come with challenges, including longer test execution times and increased complexity in test setup and maintenance. In a comprehensive testing strategy, it’s common to use a combination of unit, integration, and E2E tests to ensure software quality at various levels of granularity.

Example project setup

There isn’t a standard one-size-fits-all way of conducting E2E tests. The approach we adopt will depend on multiple factors, such as the type of application we want to test. For example, specialized test frameworks, such as Selenium, can test the user interface by emulating the behavior of real users.

However, there is one thing that all E2E setups have in common. That is, the tests run against a real system deployed in an environment that mimics the real production environment as closely as possible.

Some dependencies of the system can be faked. For example, the backend of a banking app may communicate with a sandbox that mimics a financial institution endpoint rather than a real API. However, it’ll still be set up like the real application. The client that talks to the financial institution API will be a real client sending real requests over a real network. Only the recipient of those requests may be a fake version of the service used in the production.

We demonstrate these principles in the following playground, where we run tests against a hosted application instance: