Test React Native mobile applications using Maestro, Detox, or Appium frameworks.
Scanned 9/6/2026
Install to Claude Code
npx -y skills add frank-luongt/faos-skills-marketplace --skill rn-testing --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Rn Testing?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/frank-luongt-rn-testing-faos-skills-marketplace)More formats (shields.io, HTML) on the badges page.
<!-- AUTO-GENERATED by export-skills.py — DO NOT EDIT -->
---
name: rn-testing
description: Automated testing for React Native mobile applications using Maestro, Detox, and Appium. Use when testing React Native apps, writing mobile test flows, running UI tests on iOS/Android, or automating mobile testing workflows. Covers framework selection (Maestro for simplicity, Detox for RN-native speed, Appium for cross-platform flexibility).
---
# React Native Testing
Test React Native mobile applications using Maestro, Detox, or Appium frameworks.
## When to Use
- Testing React Native apps on iOS and Android
- Writing mobile UI test flows
- Running automated regression tests on mobile
- Debugging mobile app failures
- Automating mobile testing workflows
## Framework Selection
```
New to mobile testing / AI agent workflow?
-> Maestro (simplest, YAML syntax)
React Native-only project with source code?
-> Detox (fastest for RN, automatic synchronization)
Multi-framework app or black-box testing?
-> Appium (most flexible, cross-platform)
```
| Framework | Syntax | Best For | Speed |
|---|---|---|---|
| Maestro | YAML | AI agents, quick tests | Medium |
| Detox | JavaScript/TypeScript | RN-native, gray-box | Fast |
| Appium | Python/JS/Java | Multi-framework, black-box | Slower |
## Maestro (Recommended for AI Agents)
### Create a Flow
```yaml
appId: com.myapp
---
- launchApp
- tapOn: "Login"
- inputText: "user@example.com"
- tapOn: "Password Field"
- inputText: "password123"
- tapOn: "Submit"
- assertVisible: "Welcome Screen"
```
### Use testID Props
```jsx
<Button testID="login-button" title="Login" />
```
Reference in Maestro:
```yaml
- tapOn:
id: "login-button"
```
### Run Tests
```bash
# Single flow
maestro test flows/login.yaml
# Full suite
maestro test flows/
```
### Common Scenarios
**Form validation:**
```yaml
- tapOn: "Submit"
- assertVisible: "Error: Email required"
- tapOn:
id: "email-input"
- inputText: "user@example.com"
- tapOn: "Submit"
- assertNotVisible: "Error"
```
**Navigation:**
```yaml
- launchApp
- tapOn: "Profile"
- assertVisible: "Profile Screen"
- back
- assertVisible: "Home Screen"
```
## Detox
### Prerequisites
- Detox CLI: `npm install -g detox-cli`
- `.detoxrc.js` configuration in project
- App built: `detox build --configuration ios.sim.debug`
### Run Tests
```bash
# All tests
detox test --configuration ios.sim.debug
# Specific test
detox test --configuration android.emu.debug e2e/login.test.js
# Fast iteration (reuse existing install)
detox test --configuration ios.sim.debug --reuse --cleanup false
```
## Appium
Requires Appium server running (`appium`).
```python
# Start session
session = appium_start_session(platform="android", app_path="/path/to/app.apk")
# Find and interact
email = appium_find_element(session_id=sid, strategy="accessibility_id", value="email-input")
appium_input_text(session_id=sid, element_id=eid, text="user@example.com")
appium_tap(session_id=sid, element_id=submit_id)
```
## Best Practices
1. **Use testIDs for stability** -- text may change, testIDs persist
2. **Keep flows focused** -- one scenario per file (login.yaml, checkout.yaml)
3. **Organize test files** by feature: `flows/auth/`, `flows/checkout/`, `flows/navigation/`
4. **Test critical paths first** -- login, core flows, navigation, then edge cases
5. **Use descriptive assertions** -- `assertVisible: "Welcome, John!"` not `assertVisible: "Text 1"`
## File Organization
```
flows/
auth/
login.yaml
signup.yaml
logout.yaml
checkout/
add-to-cart.yaml
complete-order.yaml
navigation/
main-menu.yaml
```
## Debugging Failed Tests
1. Check test results for error details
2. Common failures:
- **Element not found** -- verify testID, check if rendered, add timeout
- **Timing issues** -- Maestro/Detox handle automatically; Appium may need explicit waits
- **Wrong configuration** -- verify device running, app installed
## Anti-Patterns
| Avoid | Why | Instead |
|---|---|---|
| Text-based selectors | Text changes break tests | Use testID props |
| Multiple concerns per flow | Hard to debug, slow | One scenario per file |
| Skipping critical paths | Login bugs block everything | Test login first |
| Hardcoded waits | Flaky, slow | Use framework sync (Maestro/Detox) |
## Prerequisites Checklist
**Maestro**: CLI installed, emulator/simulator running, app installed
**Detox**: CLI installed, `.detoxrc.js` exists, app built for testing
**Appium**: Server installed and running, drivers installed, .apk/.app available
## References
- Source: claude-skills/rn-testing (MIT License)
- [Maestro Documentation](https://maestro.dev/)
- [Detox Documentation](https://wix.github.io/Detox/)
- [Appium Documentation](https://appium.io/)
<!-- Source: .faos/custom/skills/testing/rn-testing/SKILL.md -->
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!