qa-mobile
Mobile + mobile-web E2E testing: 11 skills covering xcuitest-suite, espresso-suite, appium-testing, detox-testing, maestro-flows, flutter-testing, mobile-device-matrix-toolkit, mobile-web-emulation-runner, touch-gesture-tester, mobile-web-perf-budget, mobile-a11y-test-author - plus 3 agents (mobile-driver-selector, mobile-test-author, mobile-test-scaffolder).
Install this plugin
/plugin install qa-mobile@testland-qaPart of role bundles: qa-role-automation-engineer, qa-role-sdet, qa-role-mobile-desktop
qa-mobile
Mobile E2E testing - closes the platform gap. Native frameworks (XCUITest for iOS + macOS desktop, Espresso for Android), cross-platform drivers (Appium, Detox, Maestro), Flutter widget/integration tests, plus a device-matrix dispatcher and mobile accessibility authoring. For mobile-WEB viewport emulation, see playwright-testing in qa-web-e2e.
Choosing a driver
Read down the "Signal in project root" column and stop at the first row that matches your project:
| Signal in project root | Driver | Why | Start with |
|---|---|---|---|
package.json with react-native in dependencies AND detox in devDependencies | Detox | Native-side gray-box runner; idle-resource synchronization avoids flake | detox-testing |
package.json with react-native, no Detox | Appium | Cross-OS black-box driver; the team can add Detox later for speed | appium-testing |
pubspec.yaml with flutter: block + lib/main.dart | flutter_test + integration_test | First-party Dart test packages; widget tests + on-device integration tests | flutter-testing |
*.xcodeproj / Package.swift targeting iOS, no package.json | XCUITest | Apple's first-party UI test harness, accessibility-tree backed, ships in Xcode | xcuitest-suite |
app/build.gradle or build.gradle.kts with com.android.application | Espresso | Google's first-party Android UI test framework, runs in the same JVM as the app | espresso-suite |
Both ios/ AND android/ dirs, no RN and no Flutter | Appium (one suite, both OSes) OR XCUITest + Espresso (one per OS) | Appium when test-team capacity is small; native + native when each OS has a dedicated team | appium-testing |
.maestro/ directory with *.yaml flowfiles | Maestro for black-box flows alongside the native driver | Declarative flowfiles survive UI churn better than imperative drivers | maestro-flows |
Tie-breakers: don't default to Appium for every cross-platform need (native drivers are faster when per-OS capacity exists); Detox needs the React Native bridge, so it never fits native-only apps; Maestro pairs WITH a native driver rather than replacing one; and don't switch driver mid-project to "fix" flake - triage the flake first (qa-flake-triage). Picking the DEVICE matrix to run against is a separate decision - see mobile-device-matrix-toolkit.
Components
| Type | Name | Description |
|---|---|---|
| Skill | xcuitest-suite | Authors XCUIest UI tests for iOS / iPadOS / tvOS and macOS desktop apps - uses the three-class XCUIApplication / XCUIElement / XCUIElementQuery pattern, sets accessibility identifiers on production code, runs via xcodebuild test with destination, parses the xcresult bundle. The macOS desktop delta (destination flags, TCC permission resets) lives in references/macos.md. Use when an iOS or macOS app needs UI tests in Apple's first-party framework (no external runtime; native to Xcode). |
| Skill | espresso-suite | Authors Espresso UI tests for Android - uses onView(withId(...)).perform(...).check(matches(...)), leans on Espresso's automatic synchronization (no Thread.sleep), wires IdlingResource for app-specific async, runs via ./gradlew connectedAndroidTest and parses the JUnit XML output. Use when an Android app needs UI tests in Google's first-party framework. |
| Skill | appium-testing | Wires Appium for cross-platform mobile UI automation - uses the WebDriver protocol, picks a driver per platform (XCUITest for iOS, UiAutomator2 / Espresso for Android, Mac2 for macOS, Windows for desktop), authors tests in JS / Python / Java / Ruby / .NET, configures desiredCapabilities, runs against simulators / emulators / device farms. Use when a single test suite must cover both iOS and Android, or when the team's stack is multi-platform (iOS + Android + Mac + Windows). |
| Skill | detox-testing | Authors React Native E2E tests using Detox (Wix) - uses gray-box architecture (test runs in-process with the app), element(by.id|by.text|by.label) matchers, waitFor() for explicit synchronization beyond Detox's automatic async tracking, and Jest as the default test runner. Use when the app is React Native and the team wants the fastest / most-reliable RN-specific framework. |
| Skill | maestro-flows | Authors mobile + web UI flows using Maestro - declarative YAML files (tapOn, inputText, assertVisible, swipe), supported targets (iOS, Android, Flutter, React Native, web), nested flow imports, JavaScript hooks for complex conditions. Use when the team wants the lowest barrier to entry for cross-platform mobile UI tests - YAML-first, no language compile step. |
| Skill | flutter-testing | Authors Flutter tests across the three-layer pyramid - unit (flutter test for pure-Dart functions), widget (testWidgets + WidgetTester for component-level UI), integration (flutter drive against simulator/emulator/device for end-to-end). Picks the right layer per change shape, mocks dependencies via mockito, runs in CI with the Flutter Action. Use when the app is Flutter and the team wants the framework's first-party testing stack. |
| Skill | mobile-device-matrix-toolkit | Dispatcher skill for orchestrating mobile UI test runs across simulators, emulators, and device farms - picks the right matrix per CI cost / coverage trade-off (3-tier model: smoke set, regression set, full release matrix), wires per-target capabilities (Appium / Detox / XCUITest), aggregates per-target JUnit XML, and emits a coverage matrix verdict. Use when a mobile suite needs to run across many target devices/OSes - directly executing 50 device configs is a CI-cost disaster; this dispatcher right-sizes per cadence. |
| Skill | mobile-a11y-test-author | Native mobile accessibility testing: iOS audits/VoiceOver, Android Espresso a11y checks/TalkBack. |
| Agent | mobile-test-author | Authors mobile UI tests end to end: detects the driver from project markers (or accepts an override), scaffolds a from-zero test skeleton when no harness exists (failing INPUT NEEDED placeholders + CI workflow stub), then emits ONE XCUITest, Espresso, Detox, Flutter, Appium, or Maestro test file per behavior spec in the driver's idiomatic patterns. Use when adding a mobile UI test - whether the test project already exists or must be scaffolded first. |
Install
/plugin marketplace add testland/qa
/plugin install qa-mobile@testland-qaSkills
appium-testing
Runs and repairs mobile UI suites driven by Appium - sessions that stop launching after an Appium server upgrade, an iOS or Android half switched off in CI because the simulator or emulator will not boot, unstable waits around one-time codes and other out-of-app steps, and locators that break on every redesign. Covers the WebDriver protocol, driver choice per platform (XCUITest for iOS, UiAutomator2 / Espresso for Android, Mac2 for macOS, Windows for desktop), `desiredCapabilities`, client bindings in JS / Python / Java / Ruby / .NET, and running against simulators, emulators, and device farms. Use when a mobile suite fails, flakes, or only runs on one platform, or when one suite must cover both iOS and Android.
detox-testing
Authors React Native E2E tests with Detox (Wix) - gray-box architecture (runs in-process with the app), `element(by.id|by.text|by.label)` matchers, `waitFor()` for explicit sync beyond Detox's automatic async tracking, Jest runner. Use when the app is React Native and speed matters. For Flutter use flutter-testing; for black-box cross-platform use appium-testing; for YAML-declarative flows use maestro-flows; for non-RN native use xcuitest-suite or espresso-suite.
espresso-suite
Authors Espresso UI tests for Android - uses `onView(withId(...)).perform(...).check(matches(...))`, leans on Espresso's automatic synchronization (no `Thread.sleep`), wires `IdlingResource` for app-specific async, runs via `./gradlew connectedAndroidTest` and parses the JUnit XML output. Use when an Android app needs UI tests in Google's first-party framework.
flutter-testing
Authors Flutter tests across the three-layer pyramid - unit (`flutter test`), widget (`testWidgets` + `WidgetTester`), integration (`integration_test` on simulator/emulator/device). Picks the right layer per change, mocks via `mockito` + `build_runner`, LCOV coverage, CI with the Flutter Action. Use when the app is Flutter and the team wants its first-party stack. For React Native use detox-testing; for black-box cross-platform use appium-testing; for YAML-declarative flows use maestro-flows.
maestro-flows
Authors Maestro YAML flow files (`.maestro/*.yaml`) for mobile + web UI automation: declarative `tapOn`, `inputText`, `assertVisible`, `swipe`, supported targets (iOS, Android, Flutter, React Native, web), nested flow imports, JavaScript hooks for complex conditions. Use when the team has already chosen Maestro, is coming from an existing `.maestro/` directory, or explicitly wants YAML-declarative tests readable by non-engineers without a compile step. For framework selection or authoring tests in XCUITest / Espresso / Detox / Appium / Flutter, use a mobile driver-selection or per-flow mobile test-authoring step instead.
mobile-a11y-test-author
Authors native mobile accessibility tests covering iOS (Accessibility Inspector, XCUITest `performAccessibilityAudit()` introduced in iOS 17, VoiceOver label/trait/hint verification) and Android (Espresso `AccessibilityChecks.enable()`, Accessibility Scanner, TalkBack traversal, `contentDescription` labelling) with WCAG-aligned checks for element labels, 44pt/48dp touch targets, contrast ratios, and focus order. Use when an iOS or Android app needs automated and manual accessibility test coverage beyond what `xcuitest-suite` or `espresso-suite` provide.
mobile-device-matrix-toolkit
Dispatches mobile UI test runs across a 3-tier device matrix (smoke per-PR, regression per-merge, full farm at release) to control CI cost: generates per-target Appium capability configs from a central YAML, parallelises via GitHub Actions matrix strategy, and aggregates JUnit XML into a cross-device pass/fail table. Use when deciding which iOS / Android devices and OS versions to run tests on and at which stage (smoke / regression / full farm), not how to configure a specific test framework (for that, use xcuitest-suite, espresso-suite, etc.).
xcuitest-suite
Authors XCUIest UI tests for iOS / iPadOS / tvOS and macOS desktop apps - uses the three-class XCUIApplication / XCUIElement / XCUIElementQuery pattern, sets accessibility identifiers on production code, runs via `xcodebuild test` with destination, parses the `xcresult` bundle. The macOS desktop delta (platform=macOS destination flags, TCC privacy-permission resets, per-device performance baselines) is in references/macos.md. Use when an iOS or macOS app needs UI tests in Apple's first-party framework (no external runtime; native to Xcode).