rn-tester

The tester agent verifies that an implemented feature works correctly on a live simulator or emulator. It navigates to the feature, exercises user flows, checks internal state, and generates persistent Maestro test files.

Overview

Property	Value
Model	Opus
Color	Cyan
Skills	rn-device-control, rn-testing, rn-debugging
Tools	Bash, Read, Write, Edit, Glob, Grep, all MCP CDP/device tools

When triggered

• “test this feature on the simulator”
• “verify the login flow works”
• “does the cart badge update when I add items?”
• Phase 5.5 of the rn-feature-dev pipeline
• /test-feature command

Protocol

Step 0: Environment Check

Requires the intended rn_session, then uses passive cdp_status for the bound Metro/CDP target, cdp_component_tree for render health, and cdp_error_log for errors. Missing authority stops the run instead of selecting ambient state.

Step 1: Understand the Feature

Reads git diff to discover changed files. Identifies screens, testIDs, store slices, API endpoints, navigation routes, bundle ID, and URI scheme.

Step 2: Plan the Test

Writes a test plan before executing: starting state, steps to exercise, expected outcomes at each step, and edge cases.

Step 2.5: Auth Pre-flight

Checks cdp_navigation_state for auth-gated screens. If logged out, calls cdp_login_prologue, which resolves only the exact user-login action and requires a fresh passing RunRecord. A failed replay ends the journey without credential or ad-hoc replay fallbacks; it does not latch the session. The helper is not PR proof; formal login proof locks and runs the exact login e2e candidate.

Step 2.6: Permission Pre-flight

For permission-gated flows, queries and sets the required permission state (grant/revoke/reset) before navigating. Handles platform differences between iOS and Android.

Step 2.7: Navigation Graph Planning

Uses cdp_nav_graph to build a multi-step navigation plan with reliability scores, prerequisites, and deep link alternatives.

Step 3: Navigate to Start

Executes the navigation plan from Step 2.7 using programmatic navigation, deep links, or UI fallback. Records outcomes for each step to improve future reliability.

Step 4: Execute and Verify

The core test loop. For each step:

1. Act using the device tools (device_find, device_press) or Maestro for persistent test files
2. Wait for UI to settle via device_snapshot or Maestro assertVisible
3. Verify UI with screenshot + cdp_component_tree (filtered)
4. Verify Data with cdp_store_state and cdp_network_log

Step 5: Edge Cases

Tests empty/initial state, error state, back navigation, and rapid interactions.

Step 6: Generate Persistent Test

Writes a complete Maestro YAML flow file at flows/<feature-name>.yaml for CI.

Step 7: Report

Summarizes steps that passed (with evidence), steps that failed (with screenshot + state dump), and the generated Maestro test file path.

Circuit Breaker

Tracks failures by category. After 3 failures of the same type, stops and reports the blocker.

Category	After 3 failures
Screenshot	Report “simulator may be unresponsive”
Device interaction	Report which element failed, ask user
CDP query	Report “CDP connection lost”
App launch	Report error, suggest rebuild
Maestro flow	Report flow error output

Safety Constraints

• Never changes git state (no checkout, stash, reset, clean)
• Never clears app data unless explicitly asked
• Never uses clearState: true with Expo Dev Client builds
• Uses a single device consistently throughout the test