Gathering detailed insights and metrics for mocha-junit-reporter
Gathering detailed insights and metrics for mocha-junit-reporter
Gathering detailed insights and metrics for mocha-junit-reporter
Gathering detailed insights and metrics for mocha-junit-reporter
npm install mocha-junit-reporter
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
144 Stars
178 Commits
153 Forks
9 Watching
5 Branches
40 Contributors
Updated on 12 Oct 2024
JavaScript (100%)
Cumulative downloads
Total Downloads
Last day
-7.4%
245,849
Compared to previous day
Last week
4.3%
1,421,345
Compared to previous week
Last month
8.7%
5,807,286
Compared to previous month
Last year
3.2%
61,915,422
Compared to previous year
Produces JUnit-style XML test results.
1$ npm install mocha-junit-reporter --save-dev
or as a global module
1$ npm install -g mocha-junit-reporter
Run mocha with mocha-junit-reporter
:
1$ mocha test --reporter mocha-junit-reporter
This will output a results file at ./test-results.xml
.
You may optionally declare an alternate location for results XML file by setting
the environment variable MOCHA_FILE
or specifying mochaFile
in reporterOptions
:
1$ MOCHA_FILE=./path_to_your/file.xml mocha test --reporter mocha-junit-reporter
or
1$ mocha test --reporter mocha-junit-reporter --reporter-options mochaFile=./path_to_your/file.xml
or
1var mocha = new Mocha({ 2 reporter: 'mocha-junit-reporter', 3 reporterOptions: { 4 mochaFile: './path_to_your/file.xml' 5 } 6});
You can also add properties to the report under testsuite
. This is useful if you want your CI environment to add extra build props to the report for analytics purposes
1<testsuites> 2 <testsuite> 3 <properties> 4 <property name="BUILD_ID" value="4291"/> 5 </properties> 6 <testcase/> 7 <testcase/> 8 <testcase/> 9 </testsuite> 10</testsuites>
To do so pass them in via env variable:
1PROPERTIES=BUILD_ID:4291 mocha test --reporter mocha-junit-reporter
or
1var mocha = new Mocha({ 2 reporter: 'mocha-junit-reporter', 3 reporterOptions: { 4 properties: { 5 BUILD_ID: 4291 6 } 7 } 8})
Results XML filename can contain [hash]
, e.g. ./path_to_your/test-results.[hash].xml
. [hash]
is replaced by MD5 hash of test results XML. This enables support of parallel execution of multiple mocha-junit-reporter
's writing test results in separate files. In addition to this these placeholders can also be used:
placeholder | output |
---|---|
[testsuitesTitle] | will be replaced by the testsuitesTitle setting |
[rootSuiteTitle] | will be replaced by the rootSuiteTitle setting |
[suiteFilename] | will be replaced by the filename of the spec file |
[suiteName] | will be replaced by the name the first test suite |
In order to display full suite title (including parents) just specify testsuitesTitle
option
1var mocha = new Mocha({ 2 reporter: 'mocha-junit-reporter', 3 reporterOptions: { 4 testsuitesTitle: true, 5 suiteTitleSeparatedBy: '.' // suites separator, default is space (' '), or period ('.') in jenkins mode 6 } 7});
If you want to switch classname and name of the generated testCase XML entries, you can use the testCaseSwitchClassnameAndName
reporter option.
1var mocha = new Mocha({ 2 reporter: 'mocha-junit-reporter', 3 reporterOptions: { 4 testCaseSwitchClassnameAndName: true 5 } 6});
Here is an example of the XML output when using the testCaseSwitchClassnameAndName
option:
value | XML output |
---|---|
true | <testcase name="should behave like so" classname="Super Suite should behave like so"> |
false (default) | <testcase name="Super Suite should behave like so" classname="should behave like so"> |
You can also configure the testsuites.name
attribute by setting reporterOptions.testsuitesTitle
and the root suite's name
attribute by setting reporterOptions.rootSuiteTitle
.
The JUnit format defines a pair of tags - <system-out/>
and <system-err/>
- for describing a test's generated output
and error streams, respectively. It is possible to pass the test outputs/errors as an array of text lines:
1it ('should report output', function () { 2 this.test.consoleOutputs = [ 'line 1 of output', 'line 2 of output' ]; 3}); 4it ('should report error', function () { 5 this.test.consoleErrors = [ 'line 1 of errors', 'line 2 of errors' ]; 6});
Since this module is only a reporter and not a self-contained test runner, it does not perform output capture itself. Thus, the author of the tests is responsible for providing a mechanism via which the outputs/errors array will be populated.
If capturing only console.log/console.error is an option, a simple (if a bit hack-ish) solution is to replace the implementations of these functions globally, like so:
1var util = require('util'); 2 3describe('my console tests', function () { 4 var originalLogFunction = console.log; 5 var originalErrorFunction = console.error; 6 beforeEach(function _mockConsoleFunctions() { 7 var currentTest = this.currentTest; 8 console.log = function captureLog() { 9 var formattedMessage = util.format.apply(util, arguments); 10 currentTest.consoleOutputs = (currentTest.consoleOutputs || []).concat(formattedMessage); 11 }; 12 console.error = function captureError() { 13 var formattedMessage = util.format.apply(util, arguments); 14 currentTest.consoleErrors = (currentTest.consoleErrors || []).concat(formattedMessage); 15 }; 16 }); 17 afterEach(function _restoreConsoleFunctions() { 18 console.log = originalLogFunction; 19 console.error = originalErrorFunction; 20 }); 21 it('should output something to the console', function() { 22 // This should end up in <system-out>: 23 console.log('hello, %s', 'world'); 24 }); 25});
Remember to run with --reporter-options outputs=true
if you want test outputs in XML.
enabling the attachments
configuration option will allow for attaching files and screenshots in JUnit Attachments Plugin format.
Attachment path can be injected into the test object
1it ('should include attachment', function () { 2 this.test.attachments = ['/absolut/path/to/file.png']; 3});
If both attachments and outputs are enabled, and a test injects both consoleOutputs and attachments, then the XML output will look like the following:
1<system-out>output line 1 2output line 2 3[[ATTACHMENT|path/to/file]]</system-out>
Parameter | Default | Effect |
---|---|---|
mochaFile | test-results.xml | configures the file to write reports to |
includePending | false | if set to a truthy value pending tests will be included in the report |
properties | null | a hash of additional properties to add to each test suite |
toConsole | false | if set to a truthy value the produced XML will be logged to the console |
useFullSuiteTitle | false | if set to a truthy value nested suites' titles will show the suite lineage |
suiteTitleSeparatedBy | (space) | the character to use to separate nested suite titles. (defaults to ' ', '.' if in jenkins mode) |
testCaseSwitchClassnameAndName | false | set to a truthy value to switch name and classname values |
rootSuiteTitle | Root Suite | the name for the root suite. (defaults to 'Root Suite') |
testsuitesTitle | Mocha Tests | the name for the testsuites tag (defaults to 'Mocha Tests') |
outputs | false | if set to truthy value will include console output and console error output |
attachments | false | if set to truthy value will attach files to report in JUnit Attachments Plugin format (after console outputs, if any) |
antMode | false | set to truthy value to return xml compatible with Ant JUnit schema |
antHostname | process.env.HOSTNAME | hostname to use when running in antMode will default to environment HOSTNAME |
jenkinsMode | false | if set to truthy value will return xml that will display nice results in Jenkins |
jenkinsClassnamePrefix | undefined | adds a prefix to a classname when running in jenkinsMode |
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
no dangerous workflow patterns detected
Reason
license file detected
Details
Reason
Found 13/22 approved changesets -- score normalized to 5
Reason
branch protection is not maximal on development and all release branches
Details
Reason
dependency not pinned by hash detected -- score normalized to 3
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
16 existing vulnerabilities detected
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More