Types of Reporters

[JamesMGreene]

In the original grand discussion thread (#1), @boneskull mentioned the desire to discuss which types of reporters should be standard as well:

So as I see it, there are potentially four types of reporters:

1. console
2. browser
3. coverage
4. custom; typically outputs to some API (TeamCity, IntelliJ, whatever)

In the spirit of DRY, it might be a good idea to provide interface(s) or mixins or some other common set of utilities.

For example, console-type reporters will typically have a toggle for color, and shouldn't display colors anyway if STDOUT is not a TTY. Browser reporters may benefit from HTML-related utilities including templating. Coverage reporters would probably want to listen to an event that reports coverage data. Since you could have an "HTML coverage" reporter, you shouldn't be locked down to a specific interface.

[cjohansen]

In my honest opinion, catering to this is probably doing to much. We should start by focusing on the interface provided by test runners. Scaffolding for reporters is much less useful to standardise, and much more a target for bikeshedding.

[jzaefferer]

This looks indeed like something that could be tackled later, if at all. I'm not so much worried about testing frameworks building reusing reporters instead of writing there own. On the other hand, testing tools that want to support any testing framework shouldn't have to deal with each one individually. That's where I think the most value is in this project.

[JamesMGreene]

I agree. While this is a worthwhile idea, it is also really beyond the scope of what we need to do in order to accomplish our goals for this particular exercise.

@boneskull: If you would like me to make another repo (e.g. "common-utils"), let me know. I can also make you an organization owner if you'd like to lead such an effort.

[boneskull]

Is the scope of this project "write a specification" or "write a specification AND implement reporters"?

If it's the latter, this is absolutely worth doing, but either way, it's not worth doing right now.

[JamesMGreene]

It's open to discussion but I would say that the scope of the project is to:

• Write a specification
• Implement the hooks/API necessary to support spec-compliant reporters within all participating unit testing frameworks

If we can also get a handful of basic reporters prototyped/implemented as well, that is definitely valuable for consumers as well as to prove out the specification.