maestro-android

name	Maestro Mobile Testing
description	Black-box mobile UI testing with Maestro YAML flows - launchApp, tapOn, inputText, assertVisible, reusable runFlow subflows, environment parameters, JUnit reporting, and emulator-based CI pipelines.
version	1.0.0
author	thetestingacademy
license	MIT
tags	["maestro","mobile","e2e","ios","android","yaml","flows","ui-testing","flutter","react-native"]
testingTypes	["mobile","e2e"]
frameworks	["appium"]
languages	["typescript"]
domains	["mobile"]
agents	["claude-code","cursor","github-copilot","windsurf","codex","aider","continue","cline","zed","bolt","gemini-cli","amp"]

Maestro Mobile Testing

This skill makes an AI agent write Maestro flows - declarative YAML files that drive iOS and Android apps black-box style with built-in waiting, no test harness compiled into the app, and no WebDriver session management. Trigger it when a repository contains a .maestro/ directory or *.yaml flows with appId: headers, or when the user wants fast, low-maintenance smoke tests for a native, React Native, or Flutter app without the weight of Appium.

Core Principles

1. Maestro waits by default; do not teach it to sleep. Every tapOn and assertVisible polls until the element appears or a timeout expires. Reach for extendedWaitUntil for slow screens; never add fixed delays as a first resort.
2. One flow per user-visible behavior. A flow named checkout-with-saved-card.yaml that does exactly that is debuggable. A 200-line regression.yaml is not. Compose bigger journeys from subflows with runFlow.
3. Select by accessibility id first, visible text second. tapOn: id: "submit-button" survives copy changes and localization; text selectors are acceptable for stable, single-language labels only.
4. Start from a clean, deterministic state. launchApp with clearState: true resets the app between flows; tests that inherit the previous flow's logged-in session fail in random orders.
5. Parameterize with env, not copies. Credentials and hosts go in env: blocks or -e KEY=value CLI arguments so the same flow runs against dev, staging, and CI builds.
6. Treat flows as code. They live in the repo next to the app, run on every PR via emulator CI, and produce JUnit XML that the pipeline understands.

Setup

# Install the Maestro CLI
curl -fsSL "https://get.maestro.mobile.dev" | bash
export PATH="$PATH:$HOME/.maestro/bin"
maestro --version

# Run one flow against the booted simulator/emulator
maestro test .maestro/login.yaml

# Run the whole suite with JUnit output for CI
maestro  .maestro/ --format junit --output maestro-report.xml


maestro studio