HTML Reporter: remove test item when hidepassed is set to true#1311
Conversation
13d3771 to
f69bb6b
Compare
|
@stefanpenner @trentmwillis sorry for the delay, but this is actually removing divs instead of hiding them when |
cecac93 to
bb94a7c
Compare
|
|
||
| QUnit.test( "passed", function( assert ) { | ||
|
|
||
| // we have to set it to 1 becuase there is currently one item being rendered, this one as it is in progress |
There was a problem hiding this comment.
There's only one item being rendered because all the test name are the same. Is this intentional?
There was a problem hiding this comment.
Well there should be 7 divs realistically, only one should exist as it is the current one.
|
@trentmwillis would you might checking this out again? 😄 |
bb94a7c to
9615597
Compare
|
just to give more info about why the appendTestsList is currently problematic. With large test base (10s of thousands of test) that behavior (iterating over each test and appending to the live dom individually) becomes a serious bottleneck. running a perf profile with ~20K tests indicates that the browser is locked up for some 20 seconds before any test even runs. |
|
Can we append the tests to an element while it's not attached to the DOM, then append that whole container to the DOM at once? I feel that would perform better, although I could be wrong. |
|
I am pretty sure it would perform better, but from our experiments it didn't seem that appending those tests up front was actually being used for anything. although, I don't know about the history of why that was originally added and what purpose it serves (if any). I did take a look at the original commit, but didn't feel i had enough context to understand the message or the implementation very much. |
|
Yeah it is basically a dead code path, since we attach a new dom node when a test is initialized anyway |
05e9bb9 to
609c846
Compare
trentmwillis
left a comment
There was a problem hiding this comment.
Looks good. One quick question though, when we toggle the tests, is it slow to add them back one-by-one? Would it be better to put them in a document fragment first then just append once? Unsure if this optimization would be useful.
|
Note waiting until I get a response to the question above ^ to merge this |
|
@trentmwillis how would we merge a document fragment with a document fragment?
I don't know if optimizing the use case of toggling between succeeded and non-succeeded cases should be done in this either. |
|
I’m not sure that splatting a fragments contents into the DOM would be any different since (in our use case) we are doing all the work synchronously anyways. Also, as @gabrielcsapo mentioned, I believe that the vast majority of the time we will not be going from one state to the other. At least in the Ember sphere, our 90%+ case would be with hidepassed on (and it is only rarely untoggled back to show the passed tests). |
Ah good point. Given the feedback, we'll ignore this for now and look at it again if someone complains :) Merging! Thanks for working on this! It'll be in the next release (which will likely be when #1307 lands). |
|
@trentmwillis #1307 looks like it will require some more work, is it possible for you guys to get a release out of current master sooner? I would like to avoid the extra work required to rollout an interim fork, obviously if thats not possible an interim fork on our end is viable. Please advise |
|
Sure, I'll cut a release tomorrow. I won't have time to get to it today. If the other PR is updated before then, it could be released together, otherwise we'll just do two separate releases. |
|
thank you @trentmwillis! |
|
@trentmwillis <3 <3 <3 |
Follows-up #1311. Since QUnit 2.7.0, when viewing a finished test run and turning on "Hide passed" and then turning it off again, resulted in the same results being shown again, but in reversed order. This was because we hide the tests from top to bottom (and push into the array), but then upon re-inserting them we used pop(), which means we first append the last test to the end of the page, but then the before-last is popped after that and appended to what is now the end of the page, etc. The end result is the tests first displaying from A-Z, then after toggling on/off, displaying from Z-A.
Follows-up #1311. Since QUnit 2.7.0, when viewing a finished test run and turning on "Hide passed" and then turning it off again, resulted in the same results being shown again, but in reversed order. This was because we hide the tests from top to bottom (and push into the array), but then upon re-inserting them we used pop(), which means we first append the last test to the end of the page, but then the before-last is popped after that and appended to what is now the end of the page, etc. The end result is the tests first displaying from A-Z, then after toggling on/off, displaying from Z-A.
Follows-up #1311. Since QUnit 2.7.0, when viewing a finished test run and turning on "Hide passed" and then turning it off again, resulted in the same results being shown again, but in reversed order. This was because we hide the tests from top to bottom (and push into the array), but then upon re-inserting them we used pop(), which means we first append the last test to the end of the page, but then the before-last is popped after that and appended to what is now the end of the page, etc. The end result is the tests first displaying from A-Z, then after toggling on/off, displaying from Z-A.
This class name is unused since QUnit 2.8.0, since #1311 changed the reporter to omit these from the DOM instead of merely visually hiding them.
Cherry-picked from 12b4cdb (3.0.0-dev): > Follows-up #1311. > > Since QUnit 2.7.0, when viewing a finished test run and turning on > "Hide passed" and then turning it off again, resulted in the same > results being shown again, but in reversed order. > > This was because we hide the tests from top to bottom (and push into > the array), but then upon re-inserting them we used pop(), which means > we first append the last test to the end of the page, but then the > before-last is popped after that and appended to what is now the end > of the page, etc. The end result is the tests first displaying from > A-Z, then after toggling on/off, displaying from Z-A.
What?
Why?
When running large test suites, rendering test output for all passing tests will cause the page to become unresponsive.
The above output is from:
While the tests are running, the page becomes more and more unresponsive while appending output items.
24280only represents the immediate children, the full child tree contains146780nodes.Solution?