A WebdriverIO plugin. Report results in junit xml format.
The easiest way is to keep wdio-junit-reporter
as a devDependency in your package.json
.
{
"devDependencies": {
"wdio-junit-reporter": "~0.3.0"
}
}
You can simple do it by:
npm install wdio-junit-reporter --save-dev
Instructions on how to install WebdriverIO
can be found here.
Following code shows the default wdio test runner configuration. Just add 'junit'
as reporter
to the array. To get some output during the test you can run the WDIO Dot Reporter and the WDIO JUnit Reporter at the same time:
// wdio.conf.js
module.exports = {
// ...
reporters: ['dot', 'junit'],
reporterOptions: {
junit: {
outputDir: './',
outputFileFormat: function(opts) { // optional
return `results-${opts.cid}.${opts.capabilities}.xml`
}
}
},
// ...
};
The following options are supported:
Define a directory where your xml files should get stored.
Type: String
Required
Define the xml files created after the test execution. You can choose to have one file (single) containing all the test suites, many files (multi) or both. Default is multi.
opts
parameter that contains the runner id as well
as the capabilities of the runner. config
parameter that represents the reporter configurationType: Object
Default: {multi: function(opts){return `WDIO.xunit.${opts.capabilities}.${opts.cid}.xml`}}
outputFileFormat: {
single: function (config) {
return 'mycustomfilename.xml';
},
multi: function (opts) {
return `WDIO.xunit.${opts.capabilities}.${opts.cid}.xml`
}
}
Gives the ability to provide custom regex for formatting test suite name (e.g. in output xml ).
Type: Regex
,
Default: /[^a-z0-9]+/
You can break out packages by an additional level by setting 'packageName'
. For example, if you wanted to iterate over a test suite with different environment variable set:
Type: String
Example:
// wdio.conf.js
module.exports = {
// ...
reporters: ['dot', 'junit'],
reporterOptions: {
junit: {
outputDir: './',
packageName: process.env.USER_ROLE // chrome.41 - administrator
}
}
// ...
};
Allows to set various combinations of error notifications inside xml.
Given a Jasmine test like expect(true).toBe(false, 'my custom message')
you will get this test error:
{
matcherName: 'toBe',
message: 'Expected true to be false, \'my custom message\'.',
stack: 'Error: Expected true to be false, \'my custom message\'.\n at UserContext.it (/home/mcelotti/Workspace/WebstormProjects/forcebeatwio/test/marco/prova1.spec.js:3:22)',
passed: false,
expected: [ false, 'my custom message' ],
actual: true
}
Therefore you can choose which key will be used where, see the example below.
Type: Object
,
Default: errorOptions: { error: "message" }
Example:
// wdio.conf.js
module.exports = {
// ...
reporters: ['dot', 'junit'],
reporterOptions: {
junit: {
outputDir: './',
errorOptions: {
error: 'message',
failure: 'message',
stacktrace: 'stack'
}
}
}
// ...
};
Last but not least you nead to tell your CI job (e.g. Jenkins) where it can find the xml file. To do that add a post-build action to your job that gets executed after the test has run and point Jenkins (or your desired CI system) to your XML test results:
If there is no such post-build step in your CI system there is probably a plugin for that somewhere on the internet.
All commands can be found in the package.json. The most important are:
Watch changes:
$ npm run watch
Run tests:
$ npm test
# run test with coverage report:
$ npm run test:cover
Build package:
$ npm build
For more information on WebdriverIO see the homepage.