ReferenceIntermediate4-6 min reference
Push Notification Testing
Push notifications fail quietly — the user just never sees them — which makes them easy to under-test. The bugs live in the permission state, the app's foreground/background state, and the payload. This sheet maps what to cover; permissions get their own depth in the Mobile Permissions sheet (linked below).
The delivery chain
App registers → gets a device token → backend sends to APNs (iOS) / FCM (Android) → OS delivers → app handles it. A break anywhere = no notification.
App state matters most
| App state | Expected |
|---|---|
| Foreground | App decides whether to show a banner; in-app handling fires |
| Background | OS shows the notification; tap routes into the app |
| Killed / not running | OS still shows it; tap cold-starts the app to the right screen |
Test all three — a notification that works backgrounded often does nothing when the app is killed.
What to test
- Permission granted / denied / revoked-later (see Mobile Permissions).
- Delivery in foreground, background, and killed states.
- Deep link / routing: tapping opens the correct screen with the right context.
- Payload: title, body, badge count, sound, data fields render correctly.
- Rich push: images/actions where used.
- Badge increments and clears correctly.
- Quiet hours / Do Not Disturb / notification settings respected.
Common mistakes
- Testing only with the app foregrounded (the easiest, least realistic state).
- Tapping a notification and not verifying it routes to the right screen.
- Ignoring the killed-app cold-start path.
- Forgetting notifications are a runtime permission on iOS and Android 13+.
- Not checking badge count reconciliation after reading.
// Related resources