This documentation is available as Markdown for AI agents and LLMs. See the full Markdown index or append .md to any documentation URL.

Learn how to automate end-to-end (E2E) tests with Maestro using Android and iOS development builds on EAS Workflows.

Broken navigation flows and crashing screens often slip past code review because reviewers cannot run the app on every pull request.

Learning outcomes

• Write Maestro flow files for navigation and screen-content tests
• Run E2E tests against Android and iOS development builds in a workflow
• Trigger E2E tests automatically on pull requests with on.pull_request or on demand with on.pull_request_labeled

The Maestro job type in EAS Workflows is currently in alpha.

Why are E2E tests useful?

The pipeline from previous chapters builds our project and delivers updates, with Slack notifications. However, a broken navigation flow or a crashing screen can still make it to production silently. E2E tests can help catch these issues before they reach production by simulating real user interactions and verifying that the app behaves as expected.

Maestro runs automated flows against a built app on an Android Emulator or an iOS Simulator. It can tap buttons, type text, assert screen content, and navigate between screens. EAS Workflows runs these flows in the cloud after building an APK for Android or an iOS Simulator build.

Set up E2E tests

For Android and iOS, we need to add a special build profile for E2E tests. This profile skips credential setup for Android and allows running our iOS build inside a simulator.

{
  %%placeholder-start%%... %%placeholder-end%%
  "build": {
    "e2e-test": {
      "withoutCredentials": true,
      "android": {
        "buildType": "apk",
        "image": "latest"
      },
      "ios": {
        "simulator": true,
        "image": "latest"
      }
    }
  }
}

appId: com.yourname.yourapp # Replace with your app's package name/bundle identifier from app config file
---
- launchApp
- assertVisible: 'Welcome'

appId: com.yourname.yourapp # Replace with your app's package name/bundle identifier from app config file
---
- launchApp
- tapOn: 'Settings'
- assertVisible: 'Settings'

Create a workflow for E2E tests

name: E2E Tests

jobs:
  build_android:
    name: Build Android for E2E
    type: build
    params:
      platform: android
      profile: e2e-test
  build_ios:
    name: Build iOS for E2E
    type: build
    params:
      platform: ios
      profile: e2e-test
  test_android:
    name: Run Maestro tests (Android)
    needs: [build_android]
    type: maestro
    params:
      build_id: ${{ needs.build_android.outputs.build_id }}
      flow_path: ['.maestro/home.yml', '.maestro/navigate.yml']
  test_ios:
    name: Run Maestro tests (iOS)
    needs: [build_ios]
    type: maestro
    params:
      build_id: ${{ needs.build_ios.outputs.build_id }}
      flow_path: ['.maestro/home.yml', '.maestro/navigate.yml']

2

Run the workflow manually

Use the eas workflow:run command to run the workflow manually:

Terminal

Copy

- eas workflow:run .eas/workflows/e2e-tests.yml

On the EAS dashboard, notice that the Android and iOS builds start in parallel. Once each build completes, the corresponding Maestro test job runs the flow files against it.

Trigger E2E tests automatically

So far we've run the workflow manually. We can trigger it from GitHub events so it runs on every pull request or on demand with a pull request label.

Run on every pull request

To run E2E tests on every pull request, add an on.pull_request trigger to the workflow:

on:
  pull_request:
    branches: ['*']

Run on demand with a label

To run E2E tests only when needed, use the on.pull_request_labeled trigger. It accepts a labels parameter, and the workflow only runs when someone adds one of those labels to a pull request. For example, we can use the test label to trigger our E2E tests workflow:

on:
  pull_request_labeled:
    labels: ['test']

Summary

In the next chapter, learn how to create a production workflow with fingerprinting and OTA updates.