Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Participate in discussion about a shared Reporter interface? #92

Closed
JamesMGreene opened this issue Sep 6, 2014 · 3 comments
Closed

Comments

@JamesMGreene
Copy link

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.
  • 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:

@jzaefferer
Copy link
Contributor

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.

@dhimil
Copy link
Contributor

dhimil commented Oct 21, 2014

@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.

@JamesMGreene
Copy link
Author

Duly noted, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants