QUnit.reporter( reporter [, options ] );

[leobalter]

After talking to Jörn today, we decided to create this reporter method to call custom reporters for QUnit.

On QUnit 2.0, it's gonna be necessary to call it even for the HTML Reporter.

This should be made on top of the new EventsEmitter interface, so it depends on #882.

To make it work and test it, we need to implement a simple custom reporter, probably a tap output. qunit-tap should be observed to avoid extra work.

Other custom reporters should follow js-reporters (on QUnit 2+) or published as other npm modules.

---

Features:

Reporter name / object

QUnit.reporter needs to be called with at least one argument identifying the reporter to be used. It might be a string with the name of the reporter or a reporter object.

TODO: The reporter object is not structured yet

Options

QUnit.reporter might be called with a second argument as an object with property options.

The main options, used as a suggested interface for most reporter are the following, with their respective defaults:

• log: console.log => the main print output method.
• error: console.error => the output method for errors.
• warn: console.warn => the output method for warnings.
• all: null => if this property is set, it replaces the values for all the other output properties: log, error, and warn.

These print options might not be used no all reporters, as it won't be used on an eventual HTML Reporter built on top of it.

Examples:

// built-in reporter
QUnit.reporter('tap');

// built-in reporter with options
QUnit.reporter('tap', {
  all: print
});

// custom reporter
QUnit.reporter(require('js-reporters-junit'));

The output on the runEnd event

The runEnd event might include a custom output property containing the printed results. This is optional on different reporters, but it can be used with different reporters, where output is an object and their children keys are the names of the reporters, their values should be strings containing the output result.

Example:

// do whatever you want with the reporter results
QUnit.on('runEnd', function(details) {
  console.log(details.output.junit);
  console.log(details.output.tap);
  fs.writeFileSync(details.output.tap);
});

This part might be made in a separate issue and it does not need to block the 2.0 Milestone.

[jzaefferer]

On QUnit 2.0, it's gonna be necessary to call it even for the HTML Reporter.

That wasn't my understanding. Unless there's a good reason to require that, I'd stick with the default.

QUnit.reporter('tap');

I'm not sure this is a good idea either. Even if QUnit bundles reporters, it should still be easy enough to get an instance and pass it to the reporter method.

QUnit.reporter(require("qunit/tap-reporter"));
QUnit.reporter(QUnit.reporters.tap);

[jzaefferer]

As far the runEnd event, I don't see why the extra property needs to be nested under an output property. I can't think of any reason why the extra property, like tap or junit, would clash with any of the existing properties.

[gibson042]

I share @jzaefferer's disinclination towards QUnit.reporter( str ), and the runEnd output seems like code talking to itself. I say YAGNI on that, but second the extra isolating property if/when we do want such functionality.

[leobalter]

As talked on the last QUnit meeting, I'm dropping this idea.

Using different reporters through npm modules should be easier to register them, like loading QUnit and qunit-tap. or any other reporter.

With the reporter being loaded, it should handle all the QUnit callbacks, it's not necessary to call QUnit.reporter.