Testing push notifications, deep links, and permission dialogs automatically requires simulating each of these platform interactions programmatically rather than waiting for a real push server round trip in every test run. For push notifications, both Android emulators and iOS simulators accept simulated notification payloads: Android supports sending a test payload through the emulator console, and iOS simulators support a command-line push tool that delivers a local APNs-formatted payload directly, letting tests verify the app's notification handling without a live backend. Deep links can be triggered directly through platform command-line tools on both Android and iOS, which open the app at the target screen exactly as a real link tap would, making deep link routing testable in isolation. Permission dialogs, such as location, camera, or notification access prompts, can be pre-granted or pre-denied before a test run using platform permission commands on Android or simulator privacy settings on iOS, avoiding flaky interaction with a system dialog that automation frameworks do not always locate reliably. Combining these techniques lets a suite cover the full notification-to-navigation flow without any manual device interaction. Nanobase AI's Mobile Test Lab automates these platform-level interactions as part of Espresso and XCUITest test generation.
Separate the plumbing from the logic
The most reliable way to test these three features is splitting each into two distinct kinds of tests. A plumbing test verifies the OS-level mechanism works: can a payload be delivered, does a deep link open the app, is a permission state correctly read. A logic test verifies what the app does with that event: does tapping a notification navigate to the right screen, does a denied permission show the correct fallback UI. Conflating the two produces tests that are flaky for the wrong reason, since a plumbing failure and a navigation bug look identical from a failed assertion alone.
Permission state matrix
| Permission state | How to set it in tests | What to assert |
|---|---|---|
| Granted | Pre-grant via platform permission command before launch | Feature works without a prompt |
| Denied | Pre-deny via platform permission command | App shows fallback UI, does not crash |
| Not yet asked | Fresh install, no pre-set state | Correct system prompt appears at the right moment |
| Restricted (iOS) | Simulator privacy settings | App handles restricted state distinctly from denied |
A suite that only tests the granted state has not actually tested permission handling, since denied and not-yet-asked are where fallback logic bugs live.
A deep link test harness in four steps
- Trigger the deep link directly through a platform command-line tool rather than simulating a tap on an external link, isolating the app's link handling from any external app behavior.
- Assert the app opens directly to the target screen, not just that the app launches.
- Repeat the trigger while the app is already running in the background, since cold-start and warm-start deep link handling are frequently implemented differently and can diverge.
- Include at least one malformed or unsupported link in the suite to verify the app fails gracefully rather than crashing.
Testing cold-start and warm-start deep link handling separately catches a real divergence that a single "app is already open" test scenario will never surface.
Why pre-setting beats tapping the dialog
Automation frameworks do not always locate system permission dialogs reliably, since these dialogs are rendered by the OS rather than the app itself. Pre-granting or pre-denying permissions before a test run through platform commands avoids that flaky interaction entirely and makes the test deterministic regardless of how the OS renders its permission UI in a given release. Removing a system dialog from the interaction path removes one of the most common sources of flakiness in this category of test.
Frequently asked questions
Can push notification tests run without a live backend?
Yes. Android emulators accept a test payload sent through the emulator console, and iOS simulators support a command-line tool that delivers a local APNs-formatted payload, letting tests verify notification handling without a real push server round trip.
Do deep link tests need a real web server?
No, deep links triggered through platform command-line tools open the app directly at the target screen exactly as a real link tap would, without requiring an actual hosted URL during the test.
How does this relate to testing camera and GPS permissions specifically?
The same pre-set permission pattern applies; see testing camera, GPS, and biometrics on emulators for hardware-specific mocking on top of the permission state.
Should permission tests run on every CI build or only nightly?
Include a representative subset, such as one granted and one denied scenario per permission-gated feature, in every CI run, since permission-handling regressions are common enough to warrant fast feedback rather than waiting for a nightly pass.
How Nanobase AI helps
Nanobase AI's Mobile Test Lab automates notification, deep link, and permission testing as part of its Espresso and XCUITest generation, structuring plumbing and logic tests separately so failures point clearly at the actual broken layer. Plumbing and logic tests are generated as separate, clearly labeled cases, so a failure points to the right layer immediately. This runs inside the same mobile CI/CD pipeline as our other Mobile Test Lab coverage.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.