Repository navigation
Share a common Reporter interface? #276
Description
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.
- an EventEmitter interface (
- 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:
Activity
dossy commentedon Oct 1, 2017
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,QUnitwhich 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 commentedon Oct 1, 2017
@dossy
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 commentedon Oct 1, 2017
@mreinstein - Thanks for the tip - I noticed that
nodeuniteven depends ontap... but the reason why I'm choosing to usenodeunitinstead oftap- I can't find any mention of assertion counting support in thetapdocumentation.nodeunithas it,qunithas it ...mocha/chaidoesn't, which is why I'm not interested in using that combination, either.dossy commentedon Oct 1, 2017
I just wish
qunitdidn't have a net 180+ package dependency tree including compiled binary packages. :-(mreinstein commentedon Oct 1, 2017
@dossy I think you're looking for this: http://www.node-tap.org/api/#tplannumber
dossy commentedon Oct 1, 2017
@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 commentedon Oct 2, 2017
FYI, for anyone who stumbles upon this issue in the future, looking for
nodeunitsupport inbrowserstack-runner, see my PR: Add support for nodeunit. PR#188.