Testing

As part of the migration process, you need to take extra steps to review your implementation and ensure that all users will be contacted correctly.

Testing the custom payload

To ensure that the payload you retrieved (see Payload) is working correctly, you need to send test notifications from the Batch dashboard to tokens associated with a version of the application that only includes the SDK of your previous push provider.

Here is how to do it:

1. Retrieve the tokens associated with your test devices for the app that include the SDK of your previous push provider only (through its dashboard, the logs of the apps that include the SDK of your previous push provider, or in the token export files).

2. Create a campaign on Batch dashboard and fill in a title, a message, and a test deeplink (also test without deeplink).

3. Add the payload from your previous push provider in the Custom Payload box:

It is possible to use the elements filled in earlier in the form by using variables in the "Custom payload" field. This will avoid you having to fill in these elements twice (which will be useful, in particular, for your real campaigns later on). The variables to use are:

{BATCH:TITLE} // notification title

{BATCH:BODY} //notification body

{BATCH:DEEPLINK} // notification deeplink

Here is an example Android payload to explain this:

{
  "body_key": "{BATCH:BODY}",
  "url_key": "{BATCH:DEEPLINK}",
  "title_key": "{BATCH:TITLE}"
}

Note : This is just an example of a payload. Yours will depend strictly on your previous push provider, your use and your implementation.

4. Send a test push to the retrieved tokens using the test functionality available in the campaign form. You will need to select "Temporary device" and then "Push token".

Specificities per OS

Unlike Android, on iOS it is not necessary to include all the payload keys that you retrieved from your previous provider. Some elements such as the title and body of the notification are handled using Apple's standard keys. These will be systematically included in the push notification sent via Batch and it will not be necessary to include them in the "Custom payload" box. Meanwhile, other elements such as the deeplink are managed by the push SDK. You will need to keep the corresponding keys.

Here is what a custom payload could look like on iOS:

{
    "test_key": "yes",
    "url_key": "{BATCH:DEEPLINK}",
    "id_key": "1234"
}

Note : This is just an example of a payload. Yours will depend strictly on your previous push provider, your use and your implementation.

Note: In order to send this test push, the authentication settings (Android / iOS) specified for both applications in Batch > Settings > Push settings must match the settings used in the test applications.

Notification reception tests

The tests are summarized in the following tables, depending on the migration type you chose.

For each test case, send a test notification from Batch dashboard or your previous provider's dashboard (see "Dashboard to use"), with or without adding the previous provider's payload (see "Use previous provider's payload?") and on the specified app (see "App to target").

It is very important to test the following elements:

• The title is displayed correctly ;
• The message is displayed correctly ;
• Deeplinks: ensure that all types of links used by your app result in the correct redirection ;
• App opens after clicking on a push without deeplink ;
• Check the format of push display on Android (reduced, extended, etc.) ;
• Push notifications are displayed in the system notification center ;
• Only one push notification is displayed.

Staged migration

Dashboard to use	Use previous provider's payload?	App to target	Expected result
Batch	Yes	App with Batch SDK	On iOS and Android, good reception of the push, and redirection if deeplink. Note: If you receive the notification twice in this test case, please check the implementation of the Interceptor.
Batch	Yes	App without Batch SDK	On iOS and Android, good reception of the push, and redirection if deeplink.
Batch	No	App without Batch SDK	Doesn't work on Android, but allows you to check that the push is received on iOS and that there is no unexpected behavior.
Batch	No	App with both SDKs	On iOS and Android, good reception of the push, and redirection if deeplink. Note: If you receive the notification twice in this test case, you will need to develop a mechanism that disables the previous provider's SDK if the Batch payload is detected. You can use the method Batch.Push.isBatchPush(RemoteMessage message) to detect if a notification comes from Batch.
Previous provider	No	App with both SDKs	On iOS and Android, good reception of the push, and redirection if deeplink.

Hot Swap

Dashboard to use	Use previous provider's payload?	App to target	Expected result
Batch	Yes	App with Batch SDK	On iOS and Android, good reception of the push, and redirection if deeplink.
Batch	Yes	App without Batch SDK	On iOS and Android, good reception of the push, and redirection if deeplink.
Batch	No	App without Batch SDK	Doesn't work on Android, but allows you to check that the push is received on iOS and that there is no unexpected behavior.

What’s next

Once the basic implementation has been tested (iOS / Android) and the tests listed above are successful, you can release your app on the stores.