Give testing its own environment
Treat the first integration as a small product flow: the player reaches an opportunity, the app requests an ad, and the experience ends with a clear result. Test that entire flow before using real traffic as feedback.
For Google Mobile Ads on Android, Google documents two testing paths: demo ad units or your own ad units with test devices. Its demo units only show Google ads. To test a mediation configuration, use the test-device approach and enable test mode for each network. Mediated ads may not display a Test Ad label. Follow each network’s current testing instructions.
Those Google-specific details are not TionAds API instructions. For a TionAds integration, use the setup supplied with your selected SDK package, app key and configured zones. The available native core is Android, with Unity, Flutter and React Native bridges.
Rehearse the moments between the callbacks
Our suggested test matrix includes ordinary success and the interruptions that happen around it. Try a slow connection. Background the app. Leave the screen before loading finishes. Decline a rewarded offer. These are product scenarios, not just integration edge cases.
For a rewarded placement, write down the intended reward behavior before running the test. Verify the reward callback and the app’s own reward handling together. A closed ad and a successfully earned reward are different events; your app’s state should reflect that distinction.
- Confirm initialization and the intended app and zone configuration.
- Observe load success, load failure, show and dismissal.
- Check that a completed reward is applied only as intended.
- Check that unavailable ads leave the app usable.
- Repeat the sequence after a background and foreground cycle.
Leave a trail the next developer can follow
Keep a brief record of the device, app build, SDK and adapter versions, format and outcome. Include enough event context to explain the sequence, while avoiding user identifiers or credentials in shared notes.
Before release, review the selected package’s production configuration instructions and the network’s rules for removing demo IDs or test settings. Make this an explicit release check rather than a detail someone has to remember.
Finally, choose what you will inspect after rollout: successful requests, impressions, errors and the in-app experience for the first cohort. A launch is easier to assess when the questions were written before the first production impression arrived.
Further reading
The technical references behind this story. Workflow suggestions are our editorial guidance.