Junit Reporter
A WebdriverIO reporter that creates Jenkins compatible XML based JUnit reports
#
InstallationThe easiest way is to keep @wdio/junit-reporter
as a devDependency in your package.json
.
You can simple do it by:
Instructions on how to install WebdriverIO
can be found here.
#
OutputThis reporter will output a report for each runner, so in turn you will receive an xml report for each spec file. Below are examples of XML output given different scenarios in the spec file.
#
Single describe blockbecomes
#
Nested describe blockbecomes
#
Multiple describe blockbecomes
#
Failures and ErrorsAll test case failures are mapped as JUnit test case errors. A failed test case due to assertion failure or error will look like:
#
ConfigurationFollowing 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:
The following options are supported:
#
outputDirDefine a directory where your xml files should get stored.
Type: String
Required
#
outputFileFormatDefine the xml files created after the test execution.
Type: Object
Default: function (opts) { return `wdio-${this.cid}-${name}-reporter.log` }
Note:
options.capabilities
is your capabilities object for that runner, so specifying${options.capabilities}
in your string will return [Object object]. You must specify which properties of capabilities you want in your filename.
#
suiteNameFormatGives the ability to provide custom regex for formatting test suite name (e.g. in output xml ).
Type: Regex
,
Default: /[^a-z0-9]+/
#
addFileAttributeAdds a file attribute to each testcase. This config is primarily for CircleCI. This setting provides richer details but may break on other CI platforms.
Type: Boolean
,
Default: false
#
packageNameYou 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:
#
errorOptionsAllows 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:
Therefore you can choose which key will be used where, see the example below.
Type: Object
,
Default: errorOptions: { error: "message" }
Example:
#
Jenkins SetupLast but not least you need 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.
For more information on WebdriverIO see the homepage.