npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

mocha-junit-spec-reporter

v2.2.1

Published

A JUnit reporter for mocha.

Downloads

292

Readme

JUnit Spec Reporter for Mocha

npm

Produces JUnit-style XML test results with an option to output Spec to console.

Installation

$ npm install mocha-junit-spec-reporter --save-dev

or as a global module

$ npm install -g mocha-junit-spec-reporter

Usage

Run mocha with mocha-junit-spec-reporter:

$ mocha test --reporter mocha-junit-spec-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:

$ MOCHA_FILE=./path_to_your/file.xml mocha test --reporter mocha-junit-spec-reporter

or

$ mocha test --reporter mocha-junit-spec-reporter --reporter-options mochaFile=./path_to_your/file.xml

or

var mocha = new Mocha({
    reporter: 'mocha-junit-spec-reporter',
    reporterOptions: {
        mochaFile: './path_to_your/file.xml'
    }
});

Append properties to testsuite

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

<testsuites>
  <testsuite>
    <properties>
      <property name="BUILD_ID" value="4291"/>
    </properties>
    <testcase/>
    <testcase/>
    <testcase/>
  </testsuite>
</testsuites>

To do so pass them in via env variable:

PROPERTIES=BUILD_ID:4291 mocha test --reporter mocha-junit-spec-reporter

or

var mocha = new Mocha({
    reporter: 'mocha-junit-spec-reporter',
    reporterOptions: {
        properties: {
            BUILD_ID: 4291
        }
    }
})

Results Report

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-spec-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

var mocha = new Mocha({
    reporter: 'mocha-junit-spec-reporter',
    reporterOptions: {
        testsuitesTitle: true,
        suiteTitleSeparatedBy: '.' // suites separator, default is space (' '), or period ('.') in jenkins mode
    }
});

If you want to switch classname and name of the generated testCase XML entries, you can use the testCaseSwitchClassnameAndName reporter option.

var mocha = new Mocha({
    reporter: 'mocha-junit-spec-reporter',
    reporterOptions: {
        testCaseSwitchClassnameAndName: true
    }
});

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.

System out and system err

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:

it ('should report output', function () {
  this.test.consoleOutputs = [ 'line 1 of output', 'line 2 of output' ];
});
it ('should report error', function () {
  this.test.consoleErrors = [ 'line 1 of errors', 'line 2 of errors' ];
});

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:

var util = require('util');

describe('my console tests', function () {
  var originalLogFunction = console.log;
  var originalErrorFunction = console.error;
  beforeEach(function _mockConsoleFunctions() {
    var currentTest = this.currentTest;
    console.log = function captureLog() {
      var formattedMessage = util.format.apply(util, arguments);
      currentTest.consoleOutputs = (currentTest.consoleOutputs || []).concat(formattedMessage);
    };
    console.error = function captureError() {
      var formattedMessage = util.format.apply(util, arguments);
      currentTest.consoleErrors = (currentTest.consoleErrors || []).concat(formattedMessage);
    };
  });
  afterEach(function _restoreConsoleFunctions() {
    console.log = originalLogFunction;
    console.error = originalErrorFunction;
  });
  it('should output something to the console', function() {
    // This should end up in <system-out>:
    console.log('hello, %s', 'world');
  });
});

Remember to run with --reporter-options outputs=true if you want test outputs in XML.

Attachments

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

it ('should include attachment', function () {
  this.test.attachments = ['/absolut/path/to/file.png'];
});

If both attachments and outputs are enabled, and a test injects both consoleOutputs and attachments, then the XML output will look like the following:

<system-out>output line 1
output line 2
[[ATTACHMENT|path/to/file]]</system-out>

Full configuration options

| 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 | | spec | false | if set to a truthy value results will be logged to the console by inheriting from the Spec reporter | | 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 |