qa-mobile
Mobile app testing: XCUITest and Espresso for native apps, Appium, Detox and Maestro across platforms, Flutter tests, and mobile accessibility checks. XCUITest also covers macOS desktop apps, and a tiered device matrix keeps CI cost down. An authoring agent (mobile-test-author) detects the driver, scaffolds a harness when none exists, and writes one test per spec. Mobile-web viewport emulation lives in qa-web-e2e.
/plugin install qa-mobile@testland-qaFirst time? Add the marketplace with /plugin marketplace add testland/qa
- Category
- Functional testing
- Version
v1.7.0- Contents
- 8 skills · 1 agent
Skills8
appium-testingUse whenever one mobile UI test suite must run on iOS and Android (native or React Native apps), or an Appium suite fails, flakes or breaks after an upgrade: XCUITest, UiAutomator2 and Espresso drivers, capabilities, clients in JS, Python, Java, Ruby or .NET, simulators, emulators and device farms.skilldetox-testingUse whenever a React Native app needs end-to-end tests with Detox: gray-box runs inside the app, by.id, by.text and by.label matchers, waitFor for extra sync, and the Jest runner.skillespresso-suiteUse whenever an Android app needs UI tests in Google's Espresso: onView with perform and check, automatic synchronization instead of sleeps, IdlingResource for app async work, ./gradlew connectedAndroidTest and JUnit XML results.skillflutter-testingUse whenever a Flutter app needs tests: unit tests with flutter test, widget tests with testWidgets and WidgetTester, integration_test on simulators, emulators or devices, choosing the layer per change, mockito with build_runner, LCOV coverage and CI.skillmaestro-flowsUse when a team uses or wants Maestro YAML flows for mobile or web UI tests that non-engineers can read: .maestro/*.yaml with tapOn, inputText, assertVisible and swipe, for iOS, Android, Flutter, React Native and web, with nested flows and JavaScript hooks.skillmobile-a11y-test-authorUse when an iOS or Android app needs accessibility tests: XCUITest performAccessibilityAudit (iOS 17+), VoiceOver labels and traits, Espresso AccessibilityChecks, Accessibility Scanner and TalkBack order, plus WCAG checks for labels, 44pt and 48dp touch targets, contrast and focus order.skillmobile-device-matrix-toolkitUse when deciding which iOS and Android devices and OS versions to test on at each stage to control CI cost: smoke per PR, regression per merge, full farm at release.skillxcuitest-suiteUse whenever an iOS, iPadOS, tvOS or macOS app needs UI tests in Apple's XCUITest: XCUIApplication, XCUIElement and queries, accessibility identifiers in app code, xcodebuild test with a destination, and reading the xcresult bundle, plus macOS specifics such as privacy permission resets.skill
Agents1
About 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.