SkarpChapter 11 of 11
Advanced Scenarios, Test Data, and Best Practices
Push beyond simple login flows into the messy realities of production: flaky networks, push notifications, deep links, and complex test data that must work across Android and iOS.
1. Framing Advanced Mobile Scenarios
From Simple to Realistic
Basic tests cover login and simple navigation. Real production failures usually appear when the environment changes: network drops, app is backgrounded, or the user returns via deep links or notifications.
Module Goals
You will design tests for flaky networks and offline behavior, automate push notifications, deep links, and app upgrades, manage cross-platform test data, and avoid brittle automation anti-patterns.
Real User Journey
Picture a user on the subway: they open your app, lose signal, tap a notification, then update the app later. Your aim is to build automated scenarios that follow this messy, realistic journey.
2. Testing Offline and Poor Network Conditions
Why Network Testing Matters
Network bugs are common. You must test fully offline behavior, slow or flaky networks, and switching between Wi‑Fi and cellular to reflect real-world conditions.
Define Expected UX States
Clarify what users should see when offline: cached data, error banners, retry buttons, and which actions are disabled vs queued for later sync.
Tools for Network Conditioning
On Android use `adb shell svc wifi|data enable/disable`. On iOS Simulator use Xcode's Network Link Conditioner profiles. Many cloud device farms also simulate poor networks.
Automated Transition Flow
Typical test: start online and load data, turn network off, trigger refresh, verify offline UI, then restore network and verify recovery. Combine with background/foreground events.
Network Testing Best Practices
Avoid hard sleeps; wait for specific UI states. Keep each test focused on one main behavior like showing an offline banner or recovering after reconnect.
3. Example: Automating Offline Recovery (Android + iOS)
Scenario Overview
Scenario: load home feed, go offline, pull to refresh, verify an offline banner, restore network, then verify the banner disappears and new data loads.
Key Code Structure
The Java test uses a `HomePage` object, toggles network using adb or a provider API, performs pull-to-refresh, then asserts on banner visibility and feed item count.
Cross-Platform Handling
Use branching logic: on Android, call `svc wifi|data` via adb; on iOS, switch a network profile. Keep the high-level test steps identical across platforms.
Visualizing the UI
Visualize a list of posts with a yellow bar at the top saying "You are offline" when the network is off. After reconnection the bar fades out and new posts appear.
4. Background, Foreground, and App Lifecycle Events
Why Lifecycle Testing
Apps can be backgrounded or killed at any time. Bugs often appear when state is not preserved correctly across background, foreground, and relaunch events.
Core Scenarios
Test: background mid-flow (e.g., checkout), system kill and cold start, and interruptions like calls or permission prompts during user actions.
Automation Techniques
Use `runAppInBackground`, `terminateApp`, and `activateApp` in Appium, or `XCUIDevice` and `ActivityScenario` in native frameworks, to simulate lifecycle transitions.
A Reusable Pattern
Navigate to a mid-flow screen, enter data, background the app, return, then assert you remain on the same screen and your input is preserved.
5. Push Notifications, Deep Links, and App Upgrades
Why Push and Deep Links Matter
Push notifications and deep links are key entry points. Tapping them should navigate to the right screen with the correct data, regardless of whether the app is killed, backgrounded, or foregrounded.
Strategies for Push Testing
Direct FCM/APNs usage in tests is hard. Use backend test endpoints, cloud-farm push APIs, or bypass push by directly opening the target screen with equivalent payload.
Deep Link Automation
Deep links are easier to automate and reuse push handling logic. On Android use `adb shell am start -a VIEW -d "myapp://product/123"`; on iOS use `xcrun simctl openurl`.
Deep Link Test Pattern
Kill or background the app, fire the deep link, then assert that the correct screen opens and parameters like product IDs or filters are correctly applied.
Testing App Upgrades
To test upgrades: install version N, create data, install version N+1, then verify data is preserved and migrations run without blocking errors. Run these in nightly or pre-release suites.
6. Example: Cross-Platform Deep Link Test
This example shows a Java test that triggers a deep link differently on Android and iOS, but uses the same assertions.
```java
@Test
public void deepLinkToProductDetails_opensCorrectScreen() throws IOException, InterruptedException {
String deepLink = "myapp://product/123";
// Ensure app is not running
terminateIfRunning();
if (isAndroid()) {
// Launch deep link via Android intent
String cmd = String.join(" ",
"adb", "-s", deviceId,
"shell", "am", "start", "-W",
"-a", "android.intent.action.VIEW",
"-d", deepLink
);
runShell(cmd);
} else {
// iOS Simulator: use simctl openurl
String cmd = String.join(" ",
"xcrun", "simctl", "openurl", "booted", deepLink
);
runShell(cmd);
}
ProductPage productPage = new ProductPage(driver);
productPage.waitForLoaded();
// Assertions
assertEquals("123", productPage.getProductId());
assertTrue(productPage.getTitle().contains("Product"));
}
private void terminateIfRunning() {
if (isAndroid()) {
driver.terminateApp("com.example.myapp");
} else {
driver.terminateApp("com.example.myapp.ios");
}
}
```
Key idea: platform-specific setup (how you fire the deep link) is isolated, while the verification logic is shared.
7. Test Data Management Across Android and iOS
Why Test Data Breaks Tests
Advanced scenarios often fail because test data is inconsistent across Android and iOS, or between runs. You need predictable, resettable data that works on both platforms.
Central Test Data Service
Use a small backend that creates known user states and resets data between runs. Your tests call it via API before starting to request users like "premium with empty cart".
Idempotent Setup
Design setup so reruns are safe: "ensure user has at least one address" instead of assuming none exist. This reduces flakiness when tests fail mid-run.
Align Environments
Run Android and iOS against the same staging backend with aligned feature flags. Clear app storage or use fresh device snapshots to avoid leftover local data.
Data Management Checklist
Ask: can you create a known-good user quickly via API, reuse the same data across platforms, and ensure tests either clean up or use disposable data?
8. Common Anti-Patterns in Mobile Automation
XPath Overuse
XPath is flexible but slow and brittle. Prefer accessibility IDs, resource IDs, and platform locators. Keep XPath as a last resort to improve speed and stability.
Giant E2E Tests
Huge tests that span many features are slow and hard to debug. Instead, create smaller, focused flows and use APIs or databases for deeper validation.
UI-Only Coverage
A UI-only strategy is inefficient. Follow a testing pyramid: many unit tests, fewer integration tests, and a thin layer of UI tests for critical user journeys.
Hard Waits vs Smart Waits
Avoid `Thread.sleep`. Use explicit waits for conditions like visibility of elements or disappearance of loading spinners to reduce flakiness.
Why This Matters
Avoiding these anti-patterns keeps your tests fast, stable, and easier to maintain as Android, iOS, and automation frameworks evolve.
9. Design Your Own Advanced Scenario
Use this thought exercise to connect concepts.
Task
Design a single realistic test case for a shopping app that combines:
- A network change
- A background/foreground transition
- Either a deep link or a push-like entry
Step-by-step prompt
- Pick a user goal (for example: "view details of a sale item and add it to cart").
- Decide when the network will change (before opening item, during add-to-cart, or on return to the app).
- Decide where the lifecycle event happens (background the app during browsing, or after tapping a notification).
- Choose deep link or push-like entry:
- Deep link example: `shopapp://sale/black-friday/item123`.
- Push-like: imagine a banner that, when tapped, opens the same screen.
- Write a 5–7 step outline in plain language:
- ...
- ...
Reflection questions
- Which steps would be platform-specific (Android vs iOS)?
- Which setup would you move to an API or test data service?
- How would you keep this test under 2 minutes in CI?
10. Quick Knowledge Check
Answer this question to reinforce key ideas.
You need to test that tapping a promotion from outside the app opens the correct product screen on both Android and iOS. Which approach is usually the most reliable and maintainable?
- Use real push notifications from FCM/APNs in every CI run and wait for them to arrive.
- Automate a deep link that uses the same routing logic as the push payload, and assert on the resulting screen.
- Record a manual test session once and replay the taps as a UI macro.
- Skip this test because it is too hard to automate reliably.
Show Answer
Answer: B) Automate a deep link that uses the same routing logic as the push payload, and assert on the resulting screen.
Deep links usually exercise the same routing logic as push payloads but are easier to automate. You can fire a deep link via adb or simctl and assert that the correct screen opens with the right data.
11. Flashcards: Key Terms and Ideas
Flip through these cards to review core concepts from this module.
- Network conditioning
- The practice of simulating different network conditions (offline, high latency, limited bandwidth) to test how an app behaves under real-world connectivity issues.
- Deep link
- A URL (like myapp://product/123) that opens a specific screen inside a mobile app, often sharing routing logic with push notification payloads.
- App lifecycle testing
- Testing how an app behaves across background, foreground, and termination events, including state preservation and recovery after OS kills.
- Test data service
- A backend utility that creates and manages predictable test data (such as users or orders) for automated tests across Android and iOS.
- XPath anti-pattern
- Overusing XPath for locating elements in mobile UI tests, which tends to be slow and brittle; better options are accessibility IDs and resource IDs.
- Testing pyramid
- A strategy that emphasizes many unit tests, fewer integration tests, and a small number of end-to-end UI tests for critical flows.
Key Terms
- XPath
- A powerful but often slow and brittle query language for locating elements in a UI hierarchy; should be used sparingly in mobile UI tests.
- Deep link
- A URL that opens a specific screen inside a mobile app, often including parameters such as IDs or filters.
- Device farm
- A cloud service that provides access to many real and virtual devices for automated mobile testing under different OS versions and conditions.
- App lifecycle
- The sequence of states a mobile app goes through (launch, foreground, background, termination) and how it preserves or restores state.
- Testing pyramid
- A conceptual model that recommends many unit tests, fewer integration tests, and a small number of end-to-end UI tests.
- Accessibility ID
- A stable identifier used for accessibility and testing to locate UI elements, exposed as contentDescription on Android and accessibilityIdentifier on iOS.
- Idempotent setup
- A test setup approach where running the setup multiple times leads to the same result, reducing flakiness and dependency on initial state.
- Push notification
- A message sent from a server to a mobile device via services like FCM (Android) or APNs (iOS), which can open or interact with an app when tapped.
- Test data service
- A dedicated service or API used to create, manage, and reset test data in a consistent way across different test runs and platforms.
- Network conditioning
- Simulating different network conditions (offline, slow, flaky) to test app robustness under realistic connectivity scenarios.