Mobile Maestro E2E
Purpose
Plan and structure Maestro end-to-end tests that exercise critical mobile user journeys on a real device/emulator, validating the app as users experience it. The mobile E2E arm of ../../testing-strategy.
When to Use
- When critical mobile E2E flows exist (auth, onboarding, checkout, core journeys) that must not break.
- Before release of flows whose failure is high-impact.
- Not for unit/component coverage (
mobile-unit-testing, mobile-component-testing), and not to E2E every screen.
Inputs
- The critical user flows and their acceptance criteria.
- A runnable build (dev build or release) and device/emulator target.
Discovery Questions
- Which flows are critical enough to warrant E2E (failure = high impact)?
- What are the stable selectors/testIDs for those flows?
- Which platforms/devices must be covered?
- What test data/auth is needed to run the flow?
Responsibilities
- Take the journeys to be covered from their Gherkin scenarios (
../../testing/gherkin-specifications) — one test per scenario, no parallel case list.
- Identify the critical-path flows to automate (not all screens).
- Define Maestro flows with stable selectors and clear assertions.
- Plan test data/auth and environment for repeatable runs.
- Integrate runs into the release process (
mobile-release) where valuable.
- Keep flows resilient (avoid brittle coordinates; prefer testIDs).
Required Workflow
- Select critical flows with the user.
- Ensure stable selectors/testIDs exist (add if missing).
- Author Maestro flows with assertions.
- Define test data/auth + target devices.
- Run on device/emulator; record pass/fail (or "unverified until run").
Decision Rules
- Select Maestro when critical mobile E2E flows exist; otherwise rely on unit/component tests.
- Automate the critical path first; add breadth only where impact justifies it.
- Prefer stable testIDs over positional/coordinate selectors.
- Run against a representative build, not a broken dev state.
Rules
- E2E complements, not replaces, unit/component tests.
- Keep flows deterministic (controlled data/auth).
- Flag unrun flows explicitly with the command.
Anti-Patterns
- E2E-ing every screen (slow, brittle, low value).
- Brittle coordinate-based selectors.
- No E2E on high-impact flows because "units pass."
- Claiming E2E coverage from flows that never ran.
Validation Checklist
Definition of Done
Maestro flows covering the critical mobile journeys, using stable selectors and deterministic data, run on a representative build (or explicitly flagged unrun), integrated into the release check where valuable.
Related Skills
../../testing-strategy, mobile-unit-testing, mobile-component-testing, mobile-release, mobile-builds, mobile-authentication.
Related Knowledge
../../../knowledge/ (critical user journeys).
Related References
../../../references/mobile/screens/, ../../../references/mobile/navigation/ when populated.
Context Loading Guidance
- Requires: the critical flows, selectors, a runnable build, device target.
- Does not require: the whole app source, unit-test detail, unrelated references.
- May load:
mobile-release for integration; mobile-authentication for auth flows.
- Stop when: critical-flow E2E is authored and run (or flagged unrun).
Token Efficiency Guidance
Focus on the critical flows and their selectors, not the entire UI. Keep flow specs concise; link screen references rather than pasting UI trees.
1---2name: mobile-maestro-e2e3description: Use to plan Maestro end-to-end tests for critical mobile flows on real device/emulator. Select Maestro when critical mobile E2E flows exist; cover the critical path (auth, checkout, core journeys) rather than every screen.4---56# Mobile Maestro E2E78## Purpose910Plan and structure Maestro end-to-end tests that exercise critical mobile user journeys on a real device/emulator, validating the app as users experience it. The mobile E2E arm of `../../testing-strategy`.1112## When to Use1314- **When critical mobile E2E flows exist** (auth, onboarding, checkout, core journeys) that must not break.15- Before release of flows whose failure is high-impact.16- **Not** for unit/component coverage (`mobile-unit-testing`, `mobile-component-testing`), and not to E2E every screen.1718## Inputs1920- The critical user flows and their acceptance criteria.21- A runnable build (dev build or release) and device/emulator target.2223## Discovery Questions2425- Which flows are critical enough to warrant E2E (failure = high impact)?26- What are the stable selectors/testIDs for those flows?27- Which platforms/devices must be covered?28- What test data/auth is needed to run the flow?2930## Responsibilities3132- Take the journeys to be covered from their **Gherkin scenarios** (`../../testing/gherkin-specifications`) — one test per scenario, no parallel case list.33- Identify the **critical-path flows** to automate (not all screens).34- Define **Maestro flows** with stable selectors and clear assertions.35- Plan **test data/auth** and environment for repeatable runs.36- Integrate runs into the release process (`mobile-release`) where valuable.37- Keep flows resilient (avoid brittle coordinates; prefer testIDs).3839## Required Workflow40411. Select critical flows with the user.422. Ensure stable selectors/testIDs exist (add if missing).433. Author Maestro flows with assertions.444. Define test data/auth + target devices.455. Run on device/emulator; record pass/fail (or "unverified until run").4647## Decision Rules4849- Select Maestro when critical mobile E2E flows exist; otherwise rely on unit/component tests.50- Automate the critical path first; add breadth only where impact justifies it.51- Prefer stable testIDs over positional/coordinate selectors.52- Run against a representative build, not a broken dev state.5354## Rules5556- E2E complements, not replaces, unit/component tests.57- Keep flows deterministic (controlled data/auth).58- Flag unrun flows explicitly with the command.5960## Anti-Patterns6162- E2E-ing every screen (slow, brittle, low value).63- Brittle coordinate-based selectors.64- No E2E on high-impact flows because "units pass."65- Claiming E2E coverage from flows that never ran.6667## Validation Checklist6869- [ ] Critical flows identified (not all screens).70- [ ] Stable selectors/testIDs in place.71- [ ] Maestro flows authored with assertions.72- [ ] Test data/auth + devices defined.73- [ ] Runs executed or flagged "unverified until run."7475## Definition of Done7677Maestro flows covering the critical mobile journeys, using stable selectors and deterministic data, run on a representative build (or explicitly flagged unrun), integrated into the release check where valuable.7879## Related Skills8081`../../testing-strategy`, `mobile-unit-testing`, `mobile-component-testing`, `mobile-release`, `mobile-builds`, `mobile-authentication`.8283## Related Knowledge8485`../../../knowledge/` (critical user journeys).8687## Related References8889`../../../references/mobile/screens/`, `../../../references/mobile/navigation/` when populated.9091## Context Loading Guidance9293- **Requires:** the critical flows, selectors, a runnable build, device target.94- **Does not require:** the whole app source, unit-test detail, unrelated references.95- **May load:** `mobile-release` for integration; `mobile-authentication` for auth flows.96- **Stop when:** critical-flow E2E is authored and run (or flagged unrun).9798## Token Efficiency Guidance99100Focus on the critical flows and their selectors, not the entire UI. Keep flow specs concise; link screen references rather than pasting UI trees.
ahtishamshahzad