Implement reporter interface #405

Closed
jzaefferer opened this Issue Jan 31, 2013 · 13 comments

Comments

5 participants
@jzaefferer
Member

jzaefferer commented Jan 31, 2013

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

This comment has been minimized.

Show comment Hide comment
@JamesMGreene

JamesMGreene Jan 31, 2013

Member

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.

Member

JamesMGreene commented Jan 31, 2013

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

This comment has been minimized.

Show comment Hide comment
@twada

twada Feb 3, 2013

👍

twada commented Feb 3, 2013

👍

@JamesMGreene

This comment has been minimized.

Show comment Hide comment
@JamesMGreene

JamesMGreene Mar 4, 2013

Member

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

Member

JamesMGreene commented Mar 4, 2013

@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

This comment has been minimized.

Show comment Hide comment
@jzaefferer

jzaefferer Mar 5, 2013

Member

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

Member

jzaefferer commented Mar 5, 2013

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

@JamesMGreene

This comment has been minimized.

Show comment Hide comment
@JamesMGreene

JamesMGreene Mar 5, 2013

Member

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

Member

JamesMGreene commented Mar 5, 2013

@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

This comment has been minimized.

Show comment Hide comment
@jzaefferer

jzaefferer Mar 5, 2013

Member

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

Member

jzaefferer commented Mar 5, 2013

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

@JamesMGreene

This comment has been minimized.

Show comment Hide comment
@JamesMGreene

JamesMGreene Mar 5, 2013

Member

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.

Member

JamesMGreene commented Mar 5, 2013

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.

@ghost ghost assigned Krinkle May 7, 2013

@Krinkle

This comment has been minimized.

Show comment Hide comment
@Krinkle

Krinkle May 7, 2013

Member

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.

Member

Krinkle commented May 7, 2013

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

This comment has been minimized.

Show comment Hide comment
@JamesMGreene

JamesMGreene May 7, 2013

Member

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

Member

JamesMGreene commented May 7, 2013

@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

This comment has been minimized.

Show comment Hide comment
@Krinkle

Krinkle May 7, 2013

Member

@JamesMGreene Yes, I intend to create such method.

Member

Krinkle commented May 7, 2013

@JamesMGreene Yes, I intend to create such method.

@Krinkle

This comment has been minimized.

Show comment Hide comment
@Krinkle

Krinkle Sep 30, 2013

Member

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 #351).
  • The final object is sent with the done event (fixes #472).
  • The reporter interface retroactively gets events for all items already in the linear model (fixes #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.

Member

Krinkle commented Sep 30, 2013

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 #351).
  • The final object is sent with the done event (fixes #472).
  • The reporter interface retroactively gets events for all items already in the linear model (fixes #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 comment has been minimized.

Show comment Hide comment
@leobalter

leobalter Oct 30, 2015

Member

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

Member

leobalter commented Oct 30, 2015

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

@jzaefferer jzaefferer referenced this issue in js-reporters/js-reporters Mar 2, 2016

Closed

Help implement js-reporters in QUnit #32

@leobalter

This comment has been minimized.

Show comment Hide comment
@leobalter

leobalter Mar 31, 2017

Member

We finally have this! \o/

Member

leobalter commented Mar 31, 2017

We finally have this! \o/

@leobalter leobalter closed this Mar 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment