E2E Testing in Application Development — What It Is, Scenarios and Tools

What is E2E Testing?

E2E testing (End-to-End) is a software testing method where a test executes a complete user path through all system components. A typical E2E scenario for a mobile application includes: launching the app, registering a new user, confirming email, performing the target action (placing an order, sending a message), and verifying the result in the interface. Each step uses real components — without stubs or mocks.

The main advantage of E2E tests is that they verify the system as a whole, including the interaction between the client side, server, databases, and third-party services. E2E tests detect issues that cannot be identified at lower levels of the test pyramid: data format mismatches between client and server, authorization errors in a real environment, and integration failures with payment gateways.

According to the World Quality Report 2023, teams that implemented E2E testing in their CI/CD pipeline reduce the number of critical defects at release by 45%. However, the execution time of a full E2E suite ranges from 20 minutes to 2 hours depending on the number of scenarios, which requires a well-thought-out parallel execution strategy.

How E2E Testing Differs from Integration Testing

The main difference lies in the scope of verification. Integration tests verify the interaction of two or three components within an application: the network layer with the repository, the database with the ViewModel. E2E tests verify the entire chain: from UI to the external backend and back. If an integration test verifies that an API request returns correct JSON, an E2E test verifies that the user sees that data on screen after the full loading cycle.

Maintenance costs also differ. Integration tests work with a controlled environment — test stubs and in-memory databases — making them stable and fast. E2E tests depend on the state of external systems, network availability, and backend versions, which increases the likelihood of false failures (flakiness). According to the Google Testing Blog (2021), E2E tests are on average 3–5 times more fragile than integration tests, requiring the implementation of retry mechanisms and stability analytics.

The choice between E2E and integration tests depends on the criticality of the scenario. Core user paths — registration, payment, account recovery — require E2E verification. Supporting scenarios — loading lists, updating a profile — can be covered by integration tests with UI checks at the individual screen level.

Which Scenarios to Cover with E2E Tests

Not every user scenario requires an E2E test. Selection criteria include three factors: frequency of path usage, cost of failure in production, and number of systems involved. A scenario that every user performs on first launch (onboarding, registration) is an obvious candidate. An admin panel scenario accessed by 5% of users is a candidate for integration testing.

• Registration and Login — the full account creation cycle, including email confirmation and session establishment. A failure blocks all new users.
• Order Placement and Payment — verifying the cart, delivery method selection, payment processing through a third-party gateway, and confirmation display.
• Password Recovery — requesting a reset, receiving an email, entering a new password, logging in with new credentials. Often breaks when server logic changes.
• Data Synchronization — creating a record on one device, verifying its appearance on another after cloud synchronization.
• Push Notifications — receiving a notification, navigating to the correct app screen, updating state after the notification.

For each scenario, a minimum set of E2E tests is defined — one happy path and one error path (e.g., expired token or unavailable server). Expanding E2E coverage beyond basic scenarios should be economically justified: the ROI of E2E tests decreases after covering 10–15 key paths, as additional E2E tests do not provide proportional improvement in quality confidence.

Tools for E2E Testing

For mobile E2E testing, there are three main categories of tools: platform-specific frameworks, cross-platform solutions, and next-generation tools. Tool selection depends on the technology stack, team qualification, and required speed of CI integration setup.

Platform-Specific Frameworks

XCUITest — Apple’s native tool for iOS, part of Xcode. The most stable and performant option for iOS, providing direct access to the system’s Accessibility layer. Espresso — Google’s native framework for Android, part of AndroidX Test. For E2E scenarios, Espresso is used together with AndroidX Test Orchestrator for test isolation and preventing mutual interference. The disadvantage of platform-specific frameworks is the need to write tests separately for each platform.

Cross-Platform Solutions

Appium — a WebDriver-based tool supporting Java, Python, JavaScript, and other languages. The Appium architecture includes a server that proxies commands to platform APIs — UIAutomator for Android and XCUITest for iOS. Desired Capabilities configuration is required for each device. Detox by Wix — a framework for React Native that synchronizes with the JS thread and automatically waits for animations and network requests to complete. Detox integrates with Jest or Mocha and requires no server setup.

Next-Generation Tools

Maestro — a modern framework that uses YAML files to describe scenarios. Maestro requires no compilation, supports hot reload, and provides a built-in Flow Report for result analysis. The tool integrates into CI in 10 minutes and automatically synchronizes with the application state, significantly reducing test flakiness compared to Appium.

• Detox (Wix) — a framework for React Native that synchronizes with the JS thread. Supports Android and iOS, automatically waits for animations and network requests to complete.
• Appium — a cross-platform WebDriver-based tool supporting any programming language.
• Maestro — a modern framework with YAML scenarios that requires no compilation and integrates into CI in 10 minutes.

Code Examples for E2E Tests

Let’s look at an E2E test for an authentication scenario in Maestro — one of the fastest-growing mobile testing tools. Maestro uses YAML format, allowing tests to be written without programming language knowledge. The second example is an E2E test in Detox for a React Native application.

Maestro: YAML Authentication Scenario

The scenario describes the complete flow: opening the app, entering email and password, clicking the login button, and verifying the main screen is displayed. Maestro commands are intuitive and require no selector configuration — the framework uses element text for lookup.

# E2E: User Login
appId: com.example.myapp
---
- launchApp
- waitForVisibile:
    text: "Email"
- tapOn:
    text: "Email"
- inputText:
    text: "user@example.com"
- tapOn:
    text: "Password"
- inputText:
    text: "secret123"
- tapOn:
    id: "loginButton"
- waitForVisibile:
    text: "Welcome back!"
- assertVisible:
    text: "Welcome back!"

Detox: E2E Test for React Native

Detox by Wix ensures test stability through automatic synchronization with the JS thread. The test doesn’t use sleep — Detox waits for all asynchronous operations to complete before checking.

describe('Login flow', () => {
    beforeEach(async () => {
        await device.reloadReactNative()
    })

    it('should login successfully', async () => {
        await expect(element(by.id('emailInput'))).toBeVisible()
        await element(by.id('emailInput')).typeText('user@example.com')
        await element(by.id('passwordInput')).typeText('secret123')
        await element(by.id('loginButton')).tap()
        await expect(element(by.text('Welcome back!'))).toBeVisible()
    })
})

E2E Testing in CI/CD Pipeline

Integrating E2E tests into CI/CD is a key factor in their effectiveness. Recommended strategy is a two-level pipeline: on every pull request, a minimal smoke suite of 3–5 critical E2E scenarios is run, and the full regression suite runs nightly (nightly build) or before a release. This approach balances feedback speed and verification depth.

Three aspects are critical for E2E tests in CI: parallelization — running tests on multiple devices simultaneously via Firebase Test Lab or AWS Device Farm reduces execution time from hours to minutes; environment containerization — using Docker for the backend and test server ensures reproducibility; reporting and retries — automatic restart of failed tests (up to 2 attempts) and HTML report generation with video of each scenario execution.

According to the Google Testing Blog (2022), teams using a dedicated E2E CI pipeline with parallel execution reduce regression detection time by 60%. The key metric for E2E test effectiveness is not the number of tests, but the percentage of successful CI runs without false failures. The target indicator is E2E suite stability above 95% with full coverage of critical paths.