AI Prompts for Planning Appium Mobile Automation
Most flaky Appium suites are planning problems: brittle XPath locators, fixed sleeps, and one page object per test. Use this prompt before writing code to get a structured automation plan you can review with your team.
The prompt
You are a mobile SDET planning Appium automation. App: [app name, native / hybrid / React Native / Flutter] Platforms: [Android versions, iOS versions] Language & runner: [e.g. Java + TestNG, Python + pytest, WebdriverIO] Flow to automate: [PASTE MANUAL TEST STEPS] Produce an automation plan, not a finished framework: 1. Screens involved and a Page Object for each, listing elements and user actions as methods. 2. Locator strategy per element in priority order: accessibilityId, resource-id (Android) / name (iOS), then predicate/UiAutomator, XPath only as last resort. Note where developers should add accessibility IDs. 3. Waits: explicit wait conditions for each step; no fixed sleeps. 4. Android vs iOS differences in this flow (permissions dialogs, keyboard, back navigation, alerts). 5. Test data and app state setup/teardown. 6. Assertions per step and what evidence to capture on failure (screenshot, page source, logs). 7. A short code skeleton for ONE page object in [language], clearly marked as untested. Do not claim the code has run.
Replace every [BRACKETED] placeholder with your own details.
Sample input: add item to cart (Android + iOS)
Fictional example written for this guide.
App: ShopLite, React Native Platforms: Android 12–14, iOS 16–17 Stack: Java + TestNG + Appium 2 (UiAutomator2 / XCUITest) Manual steps: 1. Launch app, allow notifications 2. Search "running shoes" 3. Open first result 4. Select size 42 5. Tap "Add to cart" 6. Verify cart badge shows 1
Sample AI output (illustrative, untested skeleton)
Sample output only — this shows the shape of a good answer. It has not been run, executed, or verified against a real system.
Page Objects: HomeScreen, SearchResultsScreen, ProductScreen, CartBadge (component)
ProductScreen
- sizeOption(size) → accessibilityId "size-<n>" (ask devs to add testID)
- addToCartButton → accessibilityId "add-to-cart"
- methods: selectSize(int), addToCart()
Waits
- After search: wait until first result is visible (max 10s)
- After addToCart: wait until cart badge text equals "1"
Android vs iOS
- Notification prompt: Android 13+ system dialog vs iOS alert → handle via capability autoGrantPermissions (Android) / autoAcceptAlerts (iOS) or a dedicated handler
// UNTESTED SKELETON
public class ProductScreen {
private final AppiumDriver driver;
private final WebDriverWait wait;
public ProductScreen(AppiumDriver driver) {
this.driver = driver;
this.wait = new WebDriverWait(driver, Duration.ofSeconds(10));
}
public void selectSize(int size) {
wait.until(ExpectedConditions.elementToBeClickable(
AppiumBy.accessibilityId("size-" + size))).click();
}
public void addToCart() {
driver.findElement(AppiumBy.accessibilityId("add-to-cart")).click();
}
}Locator strategy, best to worst
| Locator | Android | iOS | Notes |
|---|---|---|---|
| accessibilityId | content-desc | accessibilityIdentifier | Fast, cross-platform; ask devs to add testIDs |
| id / name | resource-id | name | Stable if not auto-generated |
| Native query | UiAutomator selector | Predicate string / class chain | Good for dynamic lists |
| XPath | Supported | Supported | Slowest and most brittle — last resort |
Page Object Model suggestions
- One class per screen; shared widgets (tab bar, toasts) as components.
- Methods describe user intent (addToCart) — never expose raw locators to tests.
- Keep assertions in tests, not in page objects, except for “screen is loaded” checks.
- Hold platform-specific locators in one place so tests stay platform-agnostic.
Waits and validation tips
- Replace Thread.sleep with explicit waits on visibility, clickability, or text.
- Keep implicit wait at 0 when using explicit waits to avoid compounded timeouts.
- Reset app state between tests (noReset / fullReset) deliberately, not by default.
- Capture screenshot + page source on failure; they make flaky failures diagnosable.
- Validate on at least one real device per platform before trusting emulator results.
QA review before you use the output
- • Check every capability and API name against the Appium 2 docs — AI often mixes v1 syntax.
- • Run the skeleton on a device before committing; the AI has not executed it.
- • Strip internal bundle IDs, build URLs, and credentials before pasting into a public AI tool.
- • AI output can be wrong or incomplete. A human tester owns the final result.
Related prompts
Need a different QA prompt?
Browse 50+ copy-ready prompts or build your own in seconds.