 |
VOOZH | about |
|
VOOZH | about |
Mobile Application Testing allows you to test and monitor key business flows for Android and iOS applications using real devices. Datadog runs these tests on real devices to provide a realistic, step-by-step representation of key application workflows, screenshots of each step, and detailed pass or fail results so your team can quickly visualize what went wrong. Mobile app tests can run on a schedule, on demand, or directly within your CI/CD pipelines.
Optionally, link Synthetic mobile test data with RUM mobile data if the RUM SDK is used within the tested application.
You can create mobile app tests in Datadog by navigating to Digital Experience > New Test and selecting Mobile Application Test.
You may create a test using one of the following options:
<KEY>:<VALUE> format to filter on a <VALUE> for a given <KEY>.When configuring a new Mobile Application test, use snippets to automatically populate your OS versions, device sizes, manufacturers, and uptime, instead of manually selecting these options. The following snippets are available:
Device Size: Automatically perform your Mobile Application tests on a specifically sized screen across devices:
OS Version: Automatically test your iOS or Android apps on multiple versions. This selection toggles to either iOS or Android depending on the choice of your Mobile Application.
Device Manufacturer (Android only): Automatically test your Android apps across multiple device manufacturers.
Uptime: Automatically configure a test with the shortest frequency available (every 15 minutes).
You can configure advanced options when creating a mobile test to dynamically adjust app behavior without modifying your code. For example, you can auto-accept alerts, allow application crashes, and capture network resources. These configurations can be accessed in the Advanced Options section of your mobile test.
You can pass key:value pairs to your application when the test starts, allowing you to programmatically modify app behavior. Your application code must be configured to explicitly read and process these key-value pairs.
Examples:
For Android tests, add the appropriate key:value pairs in the Advanced Options section of your test:
{
"username": "example_user",
"password": "{{ EXAMPLE_VARIABLE }}"
}
For iOS tests, add the appropriate key:value pairs in the Advanced Options section:
{
"username": "example_user",
"password": "{{ EXAMPLE_VARIABLE }}",
"enable_feature_x": "true"
}
On the device selection screen, you can choose to test mobile devices that are located in either Europe (EU) or the United States (US). To configure a mobile test to use either EU or US hosted devices:
Notes:
You can specify how much time a test needs to fail before triggering a notification alert.
X times after Y ms in case of failure.By default, mobile app tests are set up for on-demand testing, meaning these tests can run directly in a CI pipeline.
You can customize alert conditions to define how often you want to send an alert and the circumstances under which you want a test to send a notification alert.
X minutes.To pause test execution during planned maintenance windows, select an existing Scheduled downtime in the Downtimes section. The test automatically pauses during the downtime’s scheduled time slots.
Note: You cannot create a new downtime from the test creation form. To create one, navigate to Settings > Downtimes.
A notification is sent according to the set of alerting conditions. Use this section to define how and what to message your teams.
Enter a message or use pre-filled monitor messages for the mobile app test. This field allows standard Markdown formatting and supports the following conditional variables:
| Conditional Variable | Description |
|---|---|
{{#is_alert}} | Show when the monitor alerts. |
{{^is_alert}} | Show unless the monitor alerts. |
{{#is_recovery}} | Show when the monitor recovers from alert. |
{{^is_recovery}} | Show unless the monitor recovers from alert. |
{{#is_renotify}} | Show when the monitor renotifies. |
{{^is_renotify}} | Show unless the monitor renotifies. |
{{#is_priority}} | Show when the monitor matches priority (P1 to P5). |
{{^is_priority}} | Show unless the monitor matches priority (P1 to P5). |
Notification messages include the message defined in this section and information about the failing locations. Pre-filled monitor messages are included in the message body section:
For example, to create a monitor that iterates over steps extracting variables for mobile tests, add the following to the monitor message:
{{! List extracted variables across all successful steps }}
# Extracted variables
{{#each synthetics.attributes.result.steps}}
{{#if extractedValue}}
* **Name**: `{{extractedValue.name}}`
**Value:** {{#if extractedValue.secure}}*Obfuscated (value hidden)*{{else}}`{{{extractedValue.value}}}`{{/if}}
{{/if}}
{{/each}}
Choose team members and services to notify.
Specify a renotification frequency. To prevent renotification on failing tests, check the option Stop re-notifying on X occurrences.
Click Save & Edit Recording to save your test configuration and record your mobile app test steps.
For more information, see Synthetic Monitoring notifications.
Flakiness is a pain point in end-to-end testing. Test failures are occasionally caused by valid frontend code changes that impact an identifier, not by an actual application issue.
To prevent flaky tests, Datadog uses an algorithm that leverages a set of locators to target elements in mobile app tests. A small change in the UI may modify an element (for example, moving it to another location). The mobile app test automatically locates the element again based on points of reference that are not affected by the change.
When the test runs successfully, the mobile app test recomputes (or “self heals”) any broken locators with updated values. This ensures your tests do not break from simple UI updates and your tests are automatically adapting to your mobile application’s UI.
You can run mobile app tests in a CI pipeline by defining the mobileApplicationVersionFilePath option in a test synthetics.json file and a global configuration synthetics-ci.config file as needed. Global configuration file options take precedence over test configuration file options.
In this example, the test aaa-aaa-aaa runs with the override application version found in application/path.
// myTest.synthetics.json
{
"tests": [
{
"id": "aaa-aaa-aaa",
"testOverrides": {
"mobileApplicationVersionFilePath": "application/path"
}
}
]
}
Then, run $ datadog-ci synthetics run-tests --config synthetics-ci.config.
For more information, see Continuous Testing and CI/CD.
By default, only users with the Datadog Admin and Datadog Standard roles can create, edit, and delete Synthetic mobile app tests. To get create, edit, and delete access to Synthetic mobile app tests, upgrade your user to one of those two default roles.
If you are using the custom role feature, add your user to any custom role that includes synthetics_read and synthetics_write permissions.
Use granular access control to limit who has access to your test based on roles, teams, or individual users:
| Access level | View test configuration | Edit test configuration | View test results | Run test |
|---|---|---|---|---|
| No access | ||||
| Viewer | Yes | Yes | ||
| Editor | Yes | Yes | Yes | Yes |
Additional helpful documentation, links, and articles:
| |
