zmr-mobile-testing

ZMR Mobile Testing

Use ZMR as the typed mobile control plane for agent-led app verification. Keep model reasoning outside the runner; use ZMR for device discovery, observations, actions, waits, assertions, traces, diagnostics, and redacted evidence.

Start From App-Local State

1. Look for .zmr/config.json in the app checkout.

2. If it is missing, scaffold it:

   zmr init --app --app-id com.example.mobiletest
   

3. Run setup diagnostics before touching a device:

   zmr doctor --json --config .zmr/config.json
   zmr validate --json .zmr/android-smoke.json
   zmr validate --json .zmr/ios-smoke.json
   

Use zmr doctor --strict --json for CI-style gates.

Agent Session Pattern

Prefer a long-running JSON-RPC session for interactive agent work:

zmr serve --transport stdio --config .zmr/config.json --trace-dir traces/zmr-agent

Call methods in this order:

1. runner.capabilities
2. session.create
3. observe.semanticSnapshot for planning, or observe.snapshot for raw adapter data
4. one typed action, wait, or assertion
5. observe.semanticSnapshot
6. trace.events while the session is active
7. trace.export with redaction enabled
8. session.close

Do not scrape terminal output when CLI JSON, snapshots, action results, or trace events contain the same information.

For MCP-capable agents, start:

zmr mcp --config .zmr/config.json --trace-dir traces/zmr-agent

Use the semantic_snapshot, tap, type, wait_visible, trace_events, and trace_explore, trace_discover, and trace_export tools. Prefer semantic_snapshot because it normalizes Android and iOS hierarchy classes into roles, selectors, bounds, and recommended actions.

After a session has produced trace artifacts, prefer the review-first exploration handoff when a goal should travel with the generated scenario candidate:

{"method":"trace.explore","params":{"out":".zmr/discovered/login-smoke.json","goal":"find a stable login smoke","includeActions":true,"validate":true,"force":true}}