E2E:Best practices

E2E best practices

Use this page for guidance that applies to both Ledger Live Desktop and Ledger Live Mobile E2E tests.

Test Development Workflow

When adding a new E2E test:

1. Identify the UI elements involved in the flow.
2. Check whether the element is already identified and whether a page object or test already exists.
3. Add or update page objects before adding test steps.
4. Add the test to an existing test file when possible.
5. Run the test repeatedly before opening a pull request to reduce flakiness.

Identify Elements

Give testable elements a stable test ID at the lowest useful level in the UI tree.

Desktop uses Playwright selectors and generally relies on data-testId:

<button data-testId="onboarding-getstarted-button">Get started</button>

Mobile uses Detox matchers and generally relies on testId:

<BottomDrawer
  testId="AddAccountsModal"
  isOpen={isOpened}
  onClose={onClose}
  title={t("portfolio.emptyState.addAccounts.addAccounts")}
>

Recommended naming convention:

<context>-<text-or-purpose>-<element-type>

Example:

onboarding-getstarted-button

Page Object Model

Use the Page Object Model to keep tests readable and maintainable. Page objects group selectors and user actions for a specific screen or flow.

Benefits:

• Tests read like user journeys instead of low-level UI operations.
• Selectors are easier to update.
• Shared actions can be reused across tests.
• Reporting decorators such as @step can make Allure output easier to understand.

Platform-specific examples:

• Desktop Playwright page objects
• Mobile Detox page objects

Test Structure

Write tests as clear sequences of actions and assertions:

• Arrange the state.
• Act like a user.
• Assert the expected result.

Keep complex logic, loops, and conditionals in helpers or page objects rather than in test bodies.

Independent Tests

Each test should be able to run on its own. Never relying on the state left by a previous test. Use setup and cleanup hooks where appropriate.

Stable Waits

Do not rely on fixed sleeps when a platform-specific explicit wait is available. Wait for elements to appear, disappear, or reach the expected state.

Examples:

• Desktop: Playwright locator expectations.
• Mobile: Detox waitFor with a timeout.

Naming

Use clear names for tests, helpers, and page object methods.

Prefer names like:

should show an error on invalid password

Avoid names like:

login test 2

Xray And Test Case Links

When a test maps to a Jira/Xray test case, include the relevant test case key in the platform-specific format.

Desktop examples use B2CQA-xxx annotations and addTmsLink. Mobile CI exports results with Android and iOS execution keys. See the platform pages for examples.

Flakiness Check

Before submitting a new test, run it multiple times locally. Desktop guidance recommends running a new Playwright test at least three times before considering it stable.