Implement reporter interface

[jzaefferer]

We have JUnit, which can be improved a lot. Is there a difference to XUnit?

There's a plugin for TAP output ( https://github.com/twada/qunit-tap ), which we should at least link to, though maybe that could become an official add-on.

[JamesMGreene]

I'd love to see a generic hook for "reporters" so that people can more easily write their own as well.

As for differences between JUnit and XUnit, @gboissinot explained a little bit in #393.

[twada]

👍

[JamesMGreene]

@Krinkle Any thoughts on a "reporters" hook or config? If none are specified before QUnit.load then we could default to a theoretical "qunit-reporter-html" reporter which would basically do what QUnit core does today.

[jzaefferer]

@JamesMGreene how would that hook be different from the callbacks we have right now?

[JamesMGreene]

@jzaefferer Main difference is being able to essentially disable the default HTML reporter in favor of some othere reporter, thus reducing the work being done (and making it easier to integrate in Node.js). Does such an option already exist and I'm just unaware of It?

[jzaefferer]

You can disable the HTML reporter by not including the <div id="qunit"> element.

[JamesMGreene]

Sure, I suppose that makes total sense but it didn't dawn on me. Either way, I would like to isolate/modularize the "qunit-reporter-html" aspect of QUnit core when we tackle #378.

[Krinkle]

Making this dependant on #422. The reporter interface would be an abstraction around several event listeners.

We can then port the current html generation to be the default reporter.

[JamesMGreene]

@Krinkle: Makes sense. Should we still add a method like addReporter/reporters.add to hook them in, or just allow them to be standalone (loosely coupled)? Thinking we need the former in order to have enough knowledge as to whether to make the HTML reporter the default (or not).

[Krinkle]

@JamesMGreene Yes, I intend to create such method.

[Krinkle]

Plan for #351, #405 and #472:

• QUnit memorises the test results, gradually building an object that is essentially a data model of what is displayed in the browser.
• The individual sub-objects representing a single assertion group (e.g. "test") are sent with the testDone events (fixes testDone should provide aggregated assertion results #351).
• The final object is sent with the done event (fixes QUnit.done should provide aggregated results #472).
• The reporter interface retroactively gets events for all items already in the linear model (fixes Implement reporter interface #405).

We can also consider having a linear model as well (either in addition or instead of the data model). The difference would be that that one would only contain assertions and the logical structure would be repeated in each object (e.g. which grouping it is part of).

The linear model could then be used to e.g. extract or provide a list of failed assertions only.

[leobalter]

This is solved by #890 (before QUnit 2) and js-reporters (after QUnit 2)

[leobalter]

We finally have this! \o/