# 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 payload

To ensure that the payload you retrieved (see [Payload](/getting-started/other/implementation-guides/migration.md#push-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:

{% stepper %}
{% step %}
**Retrieve the push tokens** associated with your test devices for the app that includes 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).
{% endstep %}

{% step %}
**Create a campaign** on the Batch dashboard and fill in a title, a message, and a test deeplink (also test without deeplink).
{% endstep %}

{% step %}
**Add the payload** from your previous push provider to the Payload box:

<figure><img src="/files/bukF20XBS3FEhHoPBSJH" alt="Screenshot of the Batch campaign form highlighting the Payload box"><figcaption></figcaption></figure>

It is possible to use the elements filled in earlier in the form by using variables in the "Payload" field. This will prevent you from filling in these elements twice (which will be useful, particularly for your real campaigns later on).

The variables to use are:

```json
{BATCH:TITLE} // notification title
{BATCH:BODY} //notification body
{BATCH:DEEPLINK} // notification deeplink
```

Here is an example Android payload:

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

{% hint style="danger" %}
This is just an example of a payload. Yours will depend strictly on your previous push provider, your use, and your implementation.
{% endhint %}

{% endstep %}

{% step %}
**Send a test push** to the retrieved tokens using the test feature available in the campaign form. You will need to select "Temporary device" and then "Push token".

<figure><img src="/files/HcFaBEtw6Bq5PM8TkuAS" alt="Screenshot of the Batch campaign form highlighting the &#x22;Send a test&#x22; feature with its Push token field"><figcaption></figcaption></figure>
{% endstep %}
{% endstepper %}

### 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 "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 an example iOS payload:

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

{% hint style="danger" %}
This is just an example of a payload. Yours will depend strictly on your previous push provider, your use and your implementation.
{% endhint %}

{% hint style="danger" %}
To send this test push, the authentication settings ([Android](/developer/sdk/android.md) / [iOS](/developer/sdk/ios.md)) specified for both applications in Batch > Settings > Channels > Push must match the settings used in the test applications.
{% endhint %}

## Notification reception tests

The tests are summarized in the following tables, depending on the [migration type](/getting-started/other/implementation-guides/migration.md#migration-types) you choose.

For each test case, send a test notification from the 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 the push display on Android** (reduced, extended, etc.) ;
* Push notifications are displayed in the **system notification center** ;
* **Only one push notification** is displayed.

### Staged migration

<table><thead><tr><th width="139.14453125">Dashboard to use</th><th width="105.1875">Use previous provider's payload?</th><th width="198.7890625">App to target</th><th>Expected result</th></tr></thead><tbody><tr><td>Batch</td><td>Yes</td><td>App with Batch SDK</td><td>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 <a href="/pages/nloROx4MiTAXcpg5RfNC#android">Interceptor</a>.</td></tr><tr><td>Batch</td><td>Yes</td><td>App without Batch SDK</td><td>On iOS and Android, good reception of the push, and redirection if deeplink.</td></tr><tr><td>Batch</td><td>No</td><td>App without Batch SDK</td><td>Doesn't work on Android, but allows you to check that the push is received on iOS and that there is no unexpected behavior.</td></tr><tr><td>Batch</td><td>No</td><td>App with both SDKs</td><td>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 <a href="https://batchlabs.github.io/Batch-Android-SDK/-batch%20-android%20-s-d-k/com.batch.android/-batch/-push/is-batch-push.html?query=open%20fun%20isBatchPush(message:%20RemoteMessage):%20Boolean">isBatchPush()</a> to detect if a notification comes from Batch.</td></tr><tr><td>Previous provider</td><td>No</td><td>App with both SDKs</td><td>On iOS and Android, good reception of the push, and redirection if deeplink.</td></tr></tbody></table>

### Hot Swap

<table><thead><tr><th width="143.48046875">Dashboard to use</th><th width="100.8203125">Use previous provider's payload?</th><th width="205.84375">App to target</th><th>Expected result</th></tr></thead><tbody><tr><td>Batch</td><td>Yes</td><td>App with Batch SDK</td><td>On iOS and Android, good reception of the push, and redirection if deeplink.</td></tr><tr><td>Batch</td><td>Yes</td><td>App without Batch SDK</td><td>On iOS and Android, good reception of the push, and redirection if deeplink.</td></tr><tr><td>Batch</td><td>No</td><td>App without Batch SDK</td><td>Doesn't work on Android, but allows you to check that the push is received on iOS and that there is no unexpected behavior.</td></tr></tbody></table>

## What’s next

Once the basic implementation has been tested ([iOS](https://doc.batch.com/developer/technical-guides/how-to-guides/mobile/ios-specific/how-to-test-the-integration-on-ios) / [Android](https://doc.batch.com/developer/technical-guides/how-to-guides/mobile/android-specific/how-to-test-the-integration-on-android)) and the tests listed above are successful, you can release your app on the stores.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://doc.batch.com/getting-started/other/implementation-guides/migration/testing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.