Tap reporter (prototype yet - please come and discuss)

[leobalter]

This is my first prototype for a QUnit's native tap reporter. Following the specs for TAP version 13.

The tap output allows QUnit to be integrated anywhere that reads tap. With this prototype I would like to propose a tap adapter for js-reporter so it could (and should) read any tap result, and potentially validate.

This reporter is browser compatible and can be used anywhere with a console.log or by setting a custom print method.

QUnit.reporter( "tap" ) needs to be called to activate this reporter, this way allows extensiblity without polluting the namespace with other methods.

[trentmwillis]

Finally got around to looking at this. Overall, I like the idea. I've seen plenty of node-based shims to get reporter output so providing a default would be nice. A couple other questions:

• How would one register another reporter to use? Seems like we should define that interface so plugin authors have a standard to follow.
• Would this be the only reporter we maintain other than the HTML reporter? Similarly, how would this play with the HTML reporter? Should we support running both at the same time and will we move the HTML reporter to be initialized in a similar fashion (e.g., QUnit.reporter('html'))?

[trentmwillis]

Should we make this a bit more generic? Like:

console.log.apply(console, arguments);

I guess this depends on the circumstances under which print will be used.

[gibson042]

I love the results, but I think the interface needs some tweaking.

[trentmwillis]

Maybe this is thinking too broadly, but what if we defined an interface that reporter's then implemented? Consumers can register reporters by simply passing in an object that meets our defined interface (e.g., QUnit.setReporter(reporterInstance)) and we will invoke methods at specific points (e.g., during begin, testStart, etc.).

I think an ideal solution would be interoperable with other platforms (e.g., mocha).

[gibson042]

I agree, and think that's qunitjs/js-reporters#3 .

[trentmwillis]

@leobalter will this be superseded by the work happening in #1026? It seems like we should use the js-reporters reporter combined with the new event emitter interface.

[leobalter]

this would be fair. at least we should give a try using js-reporters.