Participate in discussion about a shared Reporter interface?
JamesMGreene opened this issue · 3 comments
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.), 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
As a likely consumer of such a shared Reporter interface, we suspect you may be interested in participating in the discussions as well. Such a reporter should eliminate the need for any framework-specific shims/plugins/etc. that you may be employing right now to standardize results.
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:
This can be closed, since the authors of this project don't seem to have much interest in participating in the discussion. It probably doesn't matter much anyway, as long as there is a result eventually, with multiple implementations. Once that's the case, a bunch of code in https://github.com/browserstack/browserstack-runner/tree/master/lib/_patch should be replaced by using that same interface.
@JamesMGreene : Thanks for the update. Sorry for getting back late. We would be more than willing to integrate the code in the setup once you have something.
Duly noted, thanks.