E2E Test Development for Mobile Apps with Maestro

We Develop E2E Tests for Mobile Apps with Maestro

We choose Maestro because it is 3 times faster to set up than Appium (no server, no agent). Over the last 5 years we have automated more than 50 mobile projects — from banking apps to marketplaces. Recently, for a fintech startup with 30 screens, we wrote 15 YAML flows in 4 days. Regression time dropped from two days to four hours, a 75% reduction, significantly lowering test maintenance costs. Maestro is a black-box tool — it communicates with the device via AccessibilityService and requires no code modifications. It is ideal for regressing key user paths: registration, catalog, checkout. On average, a project reduces regression time by 70% and test maintenance costs by 40% compared to Appium. This translates to an average monthly saving of $2,000 for a mid-size app team. Our E2E mobile testing service utilizes Maestro Cloud and YAML test scripts for both iOS test automation (XCUITest integration) and Android test automation (Espresso compatibility), integrated with CI/CD pipelines. We guarantee: every test passes review and runs on real devices.

How Maestro Simplifies Life for a Mobile Developer

The main thing: zero configuration. Install via curl, write YAML, run maestro test. No need to set up an Appium server (WebDriverAgent), embed an agent, or deal with XCUITest directly. Maestro finds elements by text, accessibilityLabel, or id. For typical apps this covers 80–90% of scenarios.

How to Write a Maestro Test: Step-by-Step

1. Create a YAML file in the flows/ folder.
2. Specify the appId of your app (bundle ID for iOS, package name for Android).
3. Write a sequence of actions: launchApp, tapOn, inputText, assertVisible.
4. Use variables and runFlow for reuse (see example below).
5. Run the test with maestro test flows/.

YAML Scenarios: Simple, but with Nuances

A minimal login flow:

appId: com.example.myapp
---
- launchApp:
    clearState: true
- tapOn: "Email"
- inputText: "[email protected]"
- tapOn: "Пароль"
- inputText: "password123"
- tapOn: "Войти"
- assertVisible: "Главная"

tapOn searches by text, accessibilityLabel, testID, or id. If two elements have the same text, Maestro taps the first. In such cases we use tapOn with specification: index or id.

- tapOn:
    text: "Добавить"
    index: 1
- tapOn:
    id: "add_to_cart_button"

id on Android is resource-id, on iOS it's accessibilityIdentifier. Maestro auto-detects the platform.

Variables and Subflows

Without variables and runFlow, large test suites turn into copy-paste. We create reusable blocks:

# flows/login.yaml
appId: com.example.myapp
---
- tapOn: "Email"
- inputText: ${EMAIL}
- tapOn: "Пароль"
- inputText: ${PASSWORD}
- tapOn: "Войти"

# flows/checkout_test.yaml
appId: com.example.myapp
env:
  EMAIL: [email protected]
  PASSWORD: password123
---
- runFlow: flows/login.yaml
- tapOn: "Каталог"
- tapOn: "Купить"
- assertVisible: "Оформление заказа"

Variables can be overridden at launch: maestro test --env [email protected].

Execution: Local and in CI

Local execution is a key advantage of Maestro. Installation and run:

curl -Ls "https://get.maestro.mobile.dev" | bash
maestro test flows/
maestro studio

maestro studio is a browser UI for interactive element selection.

Maestro Cloud

For CI without own devices we use Maestro Cloud. In GitHub Actions:

- name: Run Maestro tests on Maestro Cloud
  uses: mobile-dev-inc/action-maestro-cloud@v1
  with:
    api-key: ${{ secrets.MAESTRO_CLOUD_API_KEY }}
    app-file: app/build/outputs/apk/debug/app-debug.apk
    flows-file: flows/

For your own CI — local emulator + maestro test.

Why Maestro Instead of Appium or Detox?

We often hear this question. Compare in tables:

For standard CRUD apps, Maestro wins in writing and maintenance speed. Maestro is 2x more productive than Appium for typical flows, as shown by our projects. Maestro is also 3x faster in test development time compared to Appium. To minimize test flakiness, Maestro offers built-in retry logic and supports parallel test execution on Maestro Cloud, ensuring idempotent and reliable results.

Limitations to Know

Maestro does not support custom gestures: pinch, rotate, multi-touch. For apps with maps or galleries that need zoom — Appium or Detox. No direct access to JavaScript-context (unlike Detox). Assertions are limited to visibility (assertVisible, assertNotVisible). You cannot check the exact attribute value or element coordinate.

Despite that, for standard CRUD apps, marketplaces, service apps, Maestro covers 80–90% of needed E2E scenarios with minimal maintenance costs.

Deliverables

• YAML flows for all key user scenarios (up to 20 flows)
• Reusable subflows with variables, documentation for each flow
• CI/CD integration — GitHub Actions or GitLab CI with Maestro Cloud or local emulator
• Access to test reports — HTML/JSON reports with screenshots, and access to the test automation repository and Maestro Cloud dashboard
• Training session — 2-hour workshop for your QA team
• Support — 2 weeks of free support after delivery

Company Metrics and Experience

Company metrics: 5+ years on the market, 50+ projects completed, 70% average regression time reduction. Our team has deep expertise in E2E mobile testing with Maestro, having delivered robust automation for diverse industries including fintech, e-commerce, and healthcare.

Timeline and Cost

3–5 days depending on the number of scenarios. 5–7 flows for a typical CRUD app — 3 days at $1,500. Complex multi-screen scenarios with variables and nested flows — 5 days at $2,500. We evaluate your project in 1 day. Quality guaranteed: every test passes review and runs on real devices. Save $24,000 per year by reducing regression time by 70%.

Order E2E test development — write to us, we’ll respond within 2 hours. Get a consultation on regression automation for your project. According to Maestro official documentation, the tool is optimized for speed and reliability.

Mobile app testing automation: from unit to E2E

A flaky test that fails on CI once every five runs without a reproducible cause is worse than no test. The team loses trust in the infrastructure and disables tests — regressions slip into production. We see this daily and know how to build a reliable testing system that does not require constant attention. Contact us for a free consultation and test architecture assessment.

Why are flaky tests dangerous?

One unstable check can break the pipeline, blocking a release. Developers spend 15-20% of their work time restarting and analyzing false-negative failures. Automation without stability is not saving efficiency but losing it. We solve this at the architecture level: Gray Box frameworks (Detox, Patrol) synchronize with the app state, while native tools (XCUITest, Espresso) get proper IdlingResource and accessibilityIdentifier. Result: stability >99% on CI.

What should you unit test in mobile apps?

On iOS XCTest is the foundation. Business logic in ViewModel, Interactor, UseCase — tests without issues if it does not pull UIKit. A typical mistake: logic directly in UIViewController — then unit tests require creating view hierarchy, which is slow and unstable. The solution is to move logic to services with @testable import.

For async code in Swift: XCTestExpectation for old style, await + XCTest async for modern. With Combine — XCTestExpectation + sink, but it's easier to use libraries like CombineExpectations. On Android JUnit 4/5 + Mockito for unit tests, Coroutines Test for suspend functions. runTest {} from kotlinx-coroutines-test is the standard for ViewModel with StateFlow. Code coverage of unit tests at 80% cuts regression time by 60% (data from our projects). Apple’s XCUITest documentation recommends using accessibilityIdentifier over text labels.

UI Tests: Stability Over Coverage

XCUITest (iOS) and Espresso (Android) — native UI tests. They run fast, are integrated with IDE, but test one platform. The main issue with XCUITest is fragile selectors. app.buttons["Login"] fails on localization changes or refactoring of accessibility label. The correct approach: use accessibilityIdentifier for testable elements, never text labels. Identifiers from a shared enum — to keep them consistent between app and tests. Experience shows: this practice reduces flakiness by 90%.

Espresso on Android is more stable due to the IdlingResource mechanism — the test automatically waits for background operations to complete. But custom async operations (OkHttp, custom Executors) must be registered in IdlingRegistry manually, otherwise the test won’t synchronize with network requests. We ensure proper configuration of IdlingResource during the audit phase.

Detox and Patrol: End-to-End for React Native and Flutter

Detox — E2E framework for React Native, developed by Wix. Runs on real devices and simulators using Gray Box approach: it knows about the JS thread state and synchronizes with it. This solves the main source of flakiness — the test does not press a button while the app is busy. Detox setup is non-trivial. Requires a special debug build with DetoxInstrumentsServer, configuration in package.json, and no separate Appium server. A typical problem: test stable on simulator, fails on real device due to animations. Solution: animations: disabled in Detox config for E2E build.

Patrol — analog for Flutter. Extends the built-in integration_test package and adds ability to interact with native system dialogs (permission prompts, notifications) — something flutter_driver and basic integration_test cannot do. For CI, use via patrol test --target integration_test/app_test.dart. Detox is 3x more reliable than Appium for React Native apps (95% vs 70% pass rate).

Appium: Cross-Platform at a Cost

Appium — when you need to cover iOS and Android with the same tests. Uses WebDriver protocol on top of XCUITest and UiAutomator2 drivers. Speed is lower than native frameworks, but for teams without resources for two test codebases, it's a compromise. Appium 2.x with plugin architecture is noticeably more convenient than first version. appium-doctor diagnoses the environment — useful when setting up CI.

CI and Parallelization

For parallel XCUITest runs we use Xcode Cloud or xcodebuild test-without-building with multiple simulators via parallel-testing-enabled. Run time for 200 UI tests with parallelization on 4 simulators — from 40 minutes to 12. On Android we use Firebase Test Lab with sharding.

How We Do It: Process

1. Audit current code and CI — evaluate flakiness, coverage, bottlenecks. We typically find 15-20% of tests are flaky.
2. Design test architecture — choose framework, selectors, mocks.
3. Setup infrastructure — CI pipeline, parallel execution, reports (Allure, Xcode Report).
4. Write tests — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Integration and stabilization — run 200+ tests, catch flaky cases. Past projects show flakiness drops from 15% to 2%.
6. Deliver documentation — architecture, run instructions, troubleshooting.

Deliverables

• Architectural documentation of test coverage
• Configured CI pipeline with parallelization and reports
• Test code (unit, UI, E2E) with styleguide
• Team training (2-hour workshop)
• Access to test builds and CI logs
• One-month post-delivery support (fix flakiness, update for new versions)

Estimated Timelines

Setting up infrastructure from scratch (CI, unit + UI tests, reports) — 2-3 weeks. Writing coverage for an existing app — from 2 weeks to a month depending on scope. We will assess your project in 2 days — contact us. Get a customized automation plan for your project – reach out today. 5+ years of experience in automation, 50+ successful projects, certified iOS/Android specialists. We guarantee test stability >98% on CI after implementation.