Adopt js reporters standard#1026
Conversation
f421ec3 to
2783fd3
Compare
|
Is it just me or do you have conflict markers? |
|
is this only reusing old commits from #882? |
f421ec3 to
0c0848c
Compare
|
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.
@platinumazure yes there were, I made the rebase multiple times.
@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. |
|
The rebase is now complete, there is still work to do, but I think it is a good start 😃 |
|
I still think this needs to wait for #1025 to land, which is pretty close. |
|
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? |
|
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. |
|
Sounds good. |
| addClass( tests, "hidepass" ); | ||
| } | ||
| QUnit.on( "runStart", function( details ) { | ||
| var i, moduleObj, tests; |
There was a problem hiding this comment.
Looks like the indentation got messed up. QUnit uses tabs, not spaces.
There was a problem hiding this comment.
In other words, needs to convert from spaces back to tabs here.
There was a problem hiding this comment.
Yes, indeed. I need to change my editor config to meet QUnit coding style.
|
+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). |
|
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. |
|
Yes, I will sign the CLA. I will also rebase this again since #1025 has now landed into master. |
Every test runs without the noise of other tests, this allows to run multiple loggins tests, like events and logs.
0d89778 to
d24adb0
Compare
| testActive = true; | ||
| } ); | ||
| QUnit.log( function( details ) { | ||
| QUnit.on( "assert", function( details ) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
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. |
| runLoggingCallbacks } from "./core/logging"; | ||
| import { sourceFromStacktrace } from "./core/stacktrace"; | ||
|
|
||
| import {Suite} from "js-reporters/lib/Data"; |
|
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? |
@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 I will have another look through the code (to add comments, ... etc.) and then I will require review from the whole team 😃 |
be59024 to
1dfaa16
Compare
|
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:
@leobalter @trentmwillis @jzaefferer how you can observe from the above description the start and end of module |
|
Sorry for not keeping up with this.
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. |
I agree with you.
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. |
160f174 to
dfe9486
Compare
41be1fe to
9fd2e0e
Compare
|
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. |
|
I'm in favor of pursuing such a tool. |
|
I will start soon to develop the tool, but I need a name for it, I came up with this ones:
Which do you prefer? Or do you have other suggestions. |
|
I like standard-reporter, the other names are fine too |
|
I also like standard-reporter, it is shorter than the others 😃 |
|
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. |
No description provided.