Rules give you the ability to use decision logic to run different tests, at different times, on different builds. This enables you to treat builds, and testing suites, differently and decide what tests you want to run, and when you want to run them.
All Waldo accounts start out with a single default rule that runs all tests on all builds that are uploaded to Waldo. Feel free to edit the default rule to adapt it to your specific use case, or delete it after creating your first rule.
First, select your new rule’s triggers.
Trigger a run whenever a new build of your application is uploaded to Waldo via CI Upload or manual upload.
According to schedule
Trigger automatically a run, once a day at a specific time
Trigger a run whenever the provided code snippet is executed by your CI.
Next, choose the build version(s) to which you’d like to apply your new rule.
Choose this option if you want to allow your rule to run on any build – irrespective of the branch, package name, or variant name.
Create granular filters that allow you to select a custom set of builds based on
Use the “Add condition” button to chain multiple filters together.
Now you’re ready to select which tests you’d like to include in runs launched by your new rule.
You can also automatically add new Waldo tests – in that case, every new test you create in Waldo will be added to your rule’s test suite.
After creating your test suite, you can choose the device configurations on which Waldo will run your test suite.
Choose this option if you want your test suite to be run on every device you’ve configured in Waldo.
Choose a custom set of devices for your test suite to run on.
The list only includes devices that have been configured for your account. Contact us to add new device configurations.
Notifications are optional but are great for keeping an eye on the test results that matter most.
You can add one or more email addresses to receive an email with your test results.
Received your test results in the slack channel you want.
GitHub status check
See the pending, passing, or failing state of status checks next to individual commits in your pull request.
Updated about 1 month ago