Skip to content

Adopt js reporters standard#1026

Closed
flore77 wants to merge 28 commits into
qunitjs:masterfrom
flore77:adopt-js-reporters-standard
Closed

Adopt js reporters standard#1026
flore77 wants to merge 28 commits into
qunitjs:masterfrom
flore77:adopt-js-reporters-standard

Conversation

@flore77

@flore77 flore77 commented Aug 2, 2016

Copy link
Copy Markdown
Contributor

No description provided.

@flore77 flore77 force-pushed the adopt-js-reporters-standard branch 2 times, most recently from f421ec3 to 2783fd3 Compare August 2, 2016 21:12
@platinumazure

Copy link
Copy Markdown
Contributor

Is it just me or do you have conflict markers?

@leobalter

Copy link
Copy Markdown
Member

is this only reusing old commits from #882?

@flore77 flore77 force-pushed the adopt-js-reporters-standard branch 2 times, most recently from f421ec3 to 0c0848c Compare August 2, 2016 21:27
@flore77

flore77 commented Aug 2, 2016

Copy link
Copy Markdown
Contributor Author

This wanted to be a pr only my fork, but I made the pr into the upstream...anyway this should have arrived later, so I guess it is ok.

do you have conflict markers?

@platinumazure yes there were, I made the rebase multiple times.

is this only reusing old commits from #882?

@leobalter yes

I will ping back when I will manged to get it properly done, i.e tests will pass, or if I will get stuck.

@flore77

flore77 commented Aug 2, 2016

Copy link
Copy Markdown
Contributor Author

The rebase is now complete, there is still work to do, but I think it is a good start 😃

@jzaefferer

Copy link
Copy Markdown
Member

I still think this needs to wait for #1025 to land, which is pretty close.

@flore77

flore77 commented Aug 4, 2016

Copy link
Copy Markdown
Contributor Author

Ok.

In the meanwhile what would be the plan, to deprecate the current API, like adding an warning in 2.0, then implement the standard and to make the 3.0 release? Or to implement the API along with the old one and release a 2.x version and then on 3.0 to get rid of the old one?

@leobalter

Copy link
Copy Markdown
Member

I'm a +1 for deprecation, but I would wait for a minimal number of reporters to adapt for the new api, including the HTML Reporter (which might be covered here but I'm writing this in the go).

The new API can be released in a 2.x version, we avoid releasing new features in a major version, just features removals.

We should not worry about the warnings message in this PR, let it be done in a follow up step so we can have an easy process for each part.

@flore77

flore77 commented Aug 4, 2016

Copy link
Copy Markdown
Contributor Author

Sounds good.

Comment thread reporter/html.js Outdated
addClass( tests, "hidepass" );
}
QUnit.on( "runStart", function( details ) {
var i, moduleObj, tests;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the indentation got messed up. QUnit uses tabs, not spaces.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other words, needs to convert from spaces back to tabs here.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, indeed. I need to change my editor config to meet QUnit coding style.

@trentmwillis

Copy link
Copy Markdown
Member

+1 to what @leobalter said. Once this has landed I'd also like to see us introduce a non-browser reporter with the EventEmitter API (e.g., a TAP reporter).

@leobalter

Copy link
Copy Markdown
Member

I'm planning to rebase the tap reporter on top of this.

I'll do a proper review for this PR this week. Meanwhile, can you help us fixing the CLA issue? Maybe you'll just need to sign it and the problem is solved.

@flore77

flore77 commented Aug 7, 2016

Copy link
Copy Markdown
Contributor Author

Yes, I will sign the CLA. I will also rebase this again since #1025 has now landed into master.

@flore77 flore77 force-pushed the adopt-js-reporters-standard branch from 0d89778 to d24adb0 Compare August 9, 2016 22:41
Comment thread build/tasks/test-on-node.js Outdated
testActive = true;
} );
QUnit.log( function( details ) {
QUnit.on( "assert", function( details ) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is kinda interesting. js-reporters doesn't define an assert event. To render individual assertions in progress, its necessary.

I think its fine for QUnit to add another event, but the object should follow the spec for Assertion.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I don't find it a good idea, because then everyone could add something. make a little change etc.

Also that's why we have introduced the test assertions property on the testEnd event , which is specifically designed for this.

@jzaefferer

Copy link
Copy Markdown
Member

This currently only adopts the event names, not the event properties, right? I think I mentioned this before: Going from old events to new events, but with old properties is not a good approach. New events need to have new event properties. Makes backwards-compat harder (need old events with old props + new events with new props), but that seems the only option to me.

Comment thread src/core.js
runLoggingCallbacks } from "./core/logging";
import { sourceFromStacktrace } from "./core/stacktrace";

import {Suite} from "js-reporters/lib/Data";

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@jzaefferer

Copy link
Copy Markdown
Member

If I'm reading this correctly, this now leaves the existing callback completely alone, and adds the event emitter as its own (sub)system. Is that right? In 3.0 we'd then remove the old system?

@flore77

flore77 commented Aug 20, 2016

Copy link
Copy Markdown
Contributor Author

this now leaves the existing callback completely alone, and adds the event emitter as its own (sub)system.

@jzaefferer Yes.

I added tests to test only that the events are emitted and the order is correct (it will not always be source order, it depends on how QUnit executes the tests, but this can be treated in another pr).

Also about this tests can you explain me the setTimeout, I have seen this is done also in testing the old logging callbacks. The timeout is also to big, this tests didn't have the chance to run. I am not sure why they are influencing the other tests if I don't put them in a timeout.

To test the emitted data I must run the tests from js-reporters. Any suggestion how to do it ?

I will have another look through the code (to add comments, ... etc.) and then I will require review from the whole team 😃

@flore77 flore77 force-pushed the adopt-js-reporters-standard branch from be59024 to 1dfaa16 Compare August 21, 2016 20:06
@flore77

flore77 commented Aug 22, 2016

Copy link
Copy Markdown
Contributor Author

I have quite finished the adoption of the events and added tests to test that they are emitted and the emitting order is corect.

One problem has arise out of the nested suites testsuite.

Here is how QUnit executes the testsuite and emits on the old callbacks:

  • module: module1 > module2 starts
  • test: test2-1 starts
  • test: test2-1 ends
  • module: module1 > module2 ends
  • module: module1 > module2 > module3 starts
  • test: test3 starts
  • test: test3 ends
  • module: module1 > module2 > module3 ends
  • module: module1 > module2 starts
  • test: test2-2 starts
  • test: test2-2 ends
  • module: module1 > module2 ends
  • module: module1 starts
  • test: test1 starts
  • test: test1 ends
  • module: module1 ends

@leobalter @trentmwillis @jzaefferer how you can observe from the above description the start and end of module module1 > module2 is emitted twice. Is this considered correct ?

@trentmwillis

Copy link
Copy Markdown
Member

Sorry for not keeping up with this.

the start and end of module module1 > module2 is emitted twice. Is this considered correct ?

I don't believe so. At the least, I do not think it should be correct. The module should only start and end once, any nested modules should be a sub-set of that module, which means that their start and end is "within" the start and end of the parent module.

@flore77

flore77 commented Aug 24, 2016

Copy link
Copy Markdown
Contributor Author

The module should only start and end once

I agree with you.

any nested modules should be a sub-set of that module, which means that their start and end is "within" the start and end of the parent module

I think this is due to QUnit's flat style and that nested modules were introduced later. The js-reporters standard is how you have described it and I think I have achieved this. So I don't think it is necessary to do it also for the old callbacks, since they will be removed.

@flore77 flore77 force-pushed the adopt-js-reporters-standard branch 2 times, most recently from 160f174 to dfe9486 Compare August 31, 2016 12:30
@flore77 flore77 force-pushed the adopt-js-reporters-standard branch from 41be1fe to 9fd2e0e Compare August 31, 2016 12:37
@flore77

flore77 commented Sep 2, 2016

Copy link
Copy Markdown
Contributor Author

The implementation is almost finished, I think there should be only a little bit of work on the emitted data.

To test the emitted data it would be really good to run the tests from the js-reporters repo. But, I am not sure how to do this. What I have thought about is to pull out the tests from js-reporters and to build something like a cli-tool that would test any framework.

To achieve this, the tool would need 2 external things:

I found that from this solution all testing frameworks can benefit, also futures ones, with only a little effort they can test their reporting and know that they are compliant to the spec.

What do you think about this?

This is only an idea, so I am open to any other solution.

@gibson042

Copy link
Copy Markdown
Member

I'm in favor of pursuing such a tool.

@flore77

flore77 commented Sep 20, 2016

Copy link
Copy Markdown
Contributor Author

I will start soon to develop the tool, but I need a name for it, I came up with this ones:

  • standard-reporter
  • standard-js-reporter
  • js-reporter-compliant

Which do you prefer? Or do you have other suggestions.

@leobalter

Copy link
Copy Markdown
Member

I like standard-reporter, the other names are fine too

@flore77

flore77 commented Sep 20, 2016

Copy link
Copy Markdown
Contributor Author

I also like standard-reporter, it is shorter than the others 😃

@trentmwillis

Copy link
Copy Markdown
Member

This has been superseded by other PRs. Thanks for the initial work in spiking this out though! It was much appreciated; I am sorry that this PR wound up stalling for so long.

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

Labels

None yet

Development

Successfully merging this pull request may close these issues.

8 participants