Within this tutorial, only one Test Execution will be used; it will contain one Test Run with all the results for the different used browsers. Thus, the overall test run status will be affected by the results made for all the browsers.
Instead of this approach, a different one could be creating a Test Execution per each browser; this would require some adaptions in order to produce a XML report per each used browser. This approach would give the ability to take advantage of Test Environments (more info in Working with Test Environments).
- Install NodeJS
- Install all dependencies using "npm"
This tutorial is based on Sauce Labs's own tutorial for NodeJS.
You may start by cloning the repository https://github.com/saucelabs-sample-test-frameworks/JS-Mocha-WebdriverIO-Appium-Android
We need to cadd the dependency on
wdio-junit-reporter to generate JUnit XML reports (you have to use it for JUnit, since you cannot rely on mocha-junit-reporter since it does not handle the events from
The standard "wdio-junit-reporter" npm package can produce one or more JUnit XML reports. We'll generate the multi report file generation capability.
However, the produced JUnit XML contains testcase elements with a non-suitable classname attribute. Since "wdio-junit-reporter" is unable to customize this attribute, we need to make a change so it generates a proper attribute value. This is the reason we're using a forked version from the upstream project.
We need to configure webdriverio with the capabilities (devices/browsers) we want, along with the reporter/JUnit related configurations.
The test use the Page Objects pattern, implemented in several classes such as the following one.
Test: Verify the existence of a meny entry
Before running the test(s), you need to export some environment variables with your Sauce Lab's username along with the respective access key, which you can obtain from within the User Settings section in your Sauce Lab's profile page.
Test(s) then can be run in parallel using NPM "test" task.
After successfully running the tests and generating the JUnit XML reports (e.g. androidemulator.android.5_1.apidemos-debug_apk?raw=true.xml, samsunggalaxys4emulator.android.4_4.apidemos-debug_apk?raw=true.xml), it can be imported to Xray (either by the REST API or through the Import Execution Results action within the Test Execution).
We'll use some shell-script sugar to do that for us and at the same time populate the Test Environment field on the Test Execution issues that will be created.
In our case, two Test Executions will be created: one per each mobile device. Each one contains the same Test case.
Mocha tests are mapped to Generic Tests in Jira, and the Generic Test Definition field contains the namespace, the name of the class, and the method name that implements the Test case.
The execution screen details will provide information on the overall test run result.
In Sauce Labs you can see some info about it.