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-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 + mobile-web E2E testing - closes the platform gap. Native frameworks (XCUITest, Espresso), cross-platform drivers (Appium, Detox, Maestro), Flutter widget/integration tests, plus a device-matrix dispatcher, mobile-web emulation runner, touch-gesture tester, and mobile Web Vitals budget reference.
Components
| Type | Name | Description |
|---|---|---|
| Skill | xcuitest-suite | Authors XCUIest UI tests for iOS / iPadOS / tvOS - uses the three-class XCUIApplication / XCUIElement / XCUIElementQuery pattern, sets accessibility identifiers on production code, runs via xcodebuild test with destination, parses the xcresult bundle. Use when an iOS 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-web-emulation-runner | Builds a workflow to run web E2E tests under mobile viewports + DPRs (device pixel ratios) - uses Playwright's devices catalog (iPhone 15, Pixel 7, etc.), runs the existing test suite per-device as separate matrix shards, captures per-device screenshots for visual review, and asserts mobile-specific behaviors (touch interactions, viewport-conditional layout). Use when the web app supports mobile and the team wants regression coverage without spinning up real Android/iOS test rigs. |
| Skill | touch-gesture-tester | Verifies touch-gesture handlers (tap, double-tap, long-press, swipe, pinch, rotate, pan) work as expected under both mobile-emulation (Playwright) and native (XCUITest / Espresso / Detox) - distinguishes "mouse click handler also fires on tap" from "real touch event fired with correct properties." Use when the app has bespoke gesture handlers (custom carousels, sliders, drag-drop, pull-to-refresh) and the team needs targeted gesture verification beyond generic UI assertions. |
| Skill | mobile-perf-budget | Pure-reference skill for mobile-web performance budgets - Core Web Vitals at the 75th percentile mobile (LCP ≤2.5s, INP ≤200ms, CLS ≤0.1; FID retired March 2024 in favor of INP), Lighthouse mobile profile config, per-route resource budgets (JS bundle, image weight, font load). Use as the team's reference for "what should the mobile perf gate enforce" - paired with lighthouse-perf (the runner) and lighthouse-budget-author (the per-route author). |
| Agent | mobile-driver-selector | Action-taking agent that reads a target mobile project (ios/, android/, lib/, package.json, pubspec.yaml, *.xcodeproj, app/build.gradle) and emits one concrete mobile test driver recommendation - XCUITest, Espresso, Detox, Flutter, Appium, or Maestro - plus rationale and which preloaded SKILL.md to read next. Distinct from qa-mobile/mobile-device-matrix-toolkit (S4 - picks DEVICE matrix to run against, not the test framework). Use when starting a new mobile test project and the team has not yet committed to a driver. |
| Agent | mobile-test-author | Action-taking agent that authors ONE mobile test file per behavior spec - detects driver via mobile-driver-selector (or accepts an override), then emits one XCUITest, Espresso, Detox, Flutter, Appium, or Maestro test using the chosen driver's idiomatic patterns. Distinct from qa-shift-left/spec-to-suite-orchestrator (language-agnostic project skeleton) - narrower scope, single-file output, mobile platforms only. Sibling of qa-desktop/desktop-test-author and the per-language unit-test authors in qa-unit-tests-{net,js,jvm,python,go-rust}. Use when adding one mobile test to an existing test project. |
| Agent | mobile-test-scaffolder | Detects the platform and emits a from-zero mobile test skeleton (Detox / XCUITest / Espresso / Maestro). |
| Skill | mobile-a11y-test-author | Native mobile accessibility testing: iOS audits/VoiceOver, Android Espresso a11y checks/TalkBack. |
Install
/plugin marketplace add testland/qa
/plugin install qa-mobile@testland-qaSkills
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).
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.
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` 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.
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 mobile-driver-selector or mobile-test-author 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 the question is about which devices to run and when, not about how to configure a specific test framework (for that, use xcuitest-suite, espresso-suite, etc.).
mobile-perf-budget
Pure-reference skill for mobile-web performance budgets - Core Web Vitals at the 75th percentile mobile (LCP ≤2.5s, INP ≤200ms, CLS ≤0.1; FID retired March 2024 in favor of INP), Lighthouse mobile profile config, per-route resource budgets (JS bundle, image weight, font load). Use as the team's reference for "what should the mobile perf gate enforce" - paired with `lighthouse-perf` (the runner) and `lighthouse-budget-author` (the per-route author).
mobile-web-emulation-runner
Builds a workflow to run web E2E tests under mobile viewports + DPRs (device pixel ratios): uses Playwright's `devices` catalog (iPhone 15, Pixel 7, etc.), runs the existing test suite per-device as separate matrix shards, captures per-device screenshots for visual review, and asserts mobile-specific behaviors (touch interactions, viewport-conditional layout). Use when the web app supports mobile and the team wants regression coverage without spinning up real Android/iOS test rigs. For post-run result aggregation across device shards, use mobile-device-matrix-toolkit; for isolated gesture-sequence verification, use touch-gesture-tester.
touch-gesture-tester
Verifies touch-gesture handlers (tap, double-tap, long-press, swipe, pinch, rotate, pan) work as expected under both mobile-emulation (Playwright) and native (XCUITest / Espresso / Detox) - distinguishes "mouse click handler also fires on tap" from "real touch event fired with correct properties." Use when the app has bespoke gesture handlers (custom carousels, sliders, drag-drop, pull-to-refresh) and the team needs targeted gesture verification beyond generic UI assertions.
xcuitest-suite
Authors XCUIest UI tests for iOS / iPadOS / tvOS - uses the three-class XCUIApplication / XCUIElement / XCUIElementQuery pattern, sets accessibility identifiers on production code, runs via `xcodebuild test` with destination, parses the `xcresult` bundle. Use when an iOS app needs UI tests in Apple's first-party framework (no external runtime; native to Xcode).
Agents
mobile-driver-selector
Action-taking agent that reads a target mobile project (`ios/`, `android/`, `lib/`, `package.json`, `pubspec.yaml`, `*.xcodeproj`, `app/build.gradle`) and emits one concrete mobile test driver recommendation - XCUITest, Espresso, Detox, Flutter, Appium, or Maestro - plus rationale and which preloaded SKILL.md to read next. Distinct from `qa-mobile/mobile-device-matrix-toolkit` (picks DEVICE matrix to run against, not the test framework). Use when starting a new mobile test project and the team has not yet committed to a driver.
mobile-test-author
Action-taking agent that authors ONE mobile test file per behavior spec - detects driver via mobile-driver-selector (or accepts an override), then emits one XCUITest, Espresso, Detox, Flutter, Appium, or Maestro test using the chosen driver's idiomatic patterns. Distinct from qa-shift-left/spec-to-suite-orchestrator (language-agnostic project skeleton) - narrower scope, single-file output, mobile platforms only. Sibling of qa-desktop/desktop-test-author and the per-language unit-test authors in qa-unit-tests-{net,js,jvm,python,go-rust}. Use when adding one mobile test to an existing test project.
mobile-test-scaffolder
Builder agent that emits a from-zero mobile test project skeleton for the detected platform - `.detoxrc.js` + `e2e/` for React Native (per Detox project-setup docs), an XCUITest UI test target stub for iOS native, an `src/androidTest/` module with Gradle wiring for Android native, or a `.maestro/` flows directory for cross-platform YAML-first suites. Distinct from `mobile-driver-selector` (picks the driver) and `mobile-test-author` (writes per-flow tests against an existing project): this scaffolds the project from scratch after the driver is chosen. Use when starting a brand-new mobile test project after `mobile-driver-selector` has produced a recommendation.