Share a common Reporter interface?

[JamesMGreene]

We on the QUnit team have been discussing the possibility of working with other JS test frameworks, especially those that can be run client-side (e.g. Mocha, Jasmine, Intern, Buster, etc. — and apparently NodeUnit! 😲), to agree upon a common Reporter interface so that we could hopefully share Reporter plugins between testing frameworks.

This would most likely come in the form of:

• a common Reporter API/Interface, e.g.
  • an EventEmitter interface (.on(...)/.off(...)) OR an object with standard "hook" properties
  • maybe a standard-ish way to register a Reporter, e.g. MyLib.addReporter(x), MyLib.reporter = x;, etc.
• a minimum viable set of standardly-named events
  • an associated standard set of data/details provided for each event
• a minimum viable set of standard test status types (e.g. pass, fail, skip, todo, pending, etc.)
• updating all participating test frameworks to support this new common Reporter interface

Would you guys be interested in discussing this further with us? If so, please let me know who I should invite to participate.

Centralized Discussions: https://github.com/js-reporters/js-reporters/issues/

Cross-reference issues:

• Standard reporter interface qunitjs/qunit#531 (original discussion)
• Share a standard Reporter interface? mochajs/mocha#1326
• Share a standard Reporter interface? jasmine/jasmine#659
• Share a standard Reporter interface? theintern/intern#257
• Share a standard Reporter interface? busterjs/buster#419

[dossy]

Since this issue was opened in Sep 2014 and it's now Oct 2017, I'm guessing there's not much interest from anyone who's using nodeunit - I only recently started using it and enjoy its lightweight nature (vs., say, QUnit which is too kitchen-sinky for my taste).

Since I want to keep using nodeunit, and I just recently decided I want to use BrowserStack for automated JS testing, I need this, so I'll work on it a bit.

[mreinstein]

@dossy

I only recently started using it and enjoy its lightweight nature

I agree lightweight testing frameworks are the way to go. I highly, highly recommend checking out tap. It's under active development, it's extremely well supported.

This project is barely maintained. It was created way back in the early days of node, and there's a lot of cruft.

[dossy]

@mreinstein - Thanks for the tip - I noticed that nodeunit even depends on tap ... but the reason why I'm choosing to use nodeunit instead of tap - I can't find any mention of assertion counting support in the tap documentation. nodeunit has it, qunit has it ... mocha/chai doesn't, which is why I'm not interested in using that combination, either.

[dossy]

I just wish qunit didn't have a net 180+ package dependency tree including compiled binary packages. :-(

[mreinstein]

I can't find any mention of assertion counting support in the tap documentation

@dossy I think you're looking for this: http://www.node-tap.org/api/#tplannumber

[dossy]

@mreinstein - Indeed. Unfortunate that TAP deviated from the expect() method name, made it less obvious to find. Anyway, I suppose we should take this discussion to email or some other direct medium and not pollute this project's issue tracker with off-topic discussion. ;)

[dossy]

FYI, for anyone who stumbles upon this issue in the future, looking for nodeunit support in browserstack-runner, see my PR: Add support for nodeunit. PR#188.