Skip to content

HTML Reporter: remove test item when hidepassed is set to true#1311

Merged
trentmwillis merged 2 commits intoqunitjs:masterfrom
gabrielcsapo:hidepassed-should-remove-test-item
Oct 9, 2018
Merged

HTML Reporter: remove test item when hidepassed is set to true#1311
trentmwillis merged 2 commits intoqunitjs:masterfrom
gabrielcsapo:hidepassed-should-remove-test-item

Conversation

@gabrielcsapo
Copy link
Copy Markdown
Contributor

What?

  • make hidepassed remove item from div rather than just hiding it

Why?

When running large test suites, rendering test output for all passing tests will cause the page to become unresponsive.

> document.querySelector('#qunit-tests').children.length
> 24280

The above output is from:

81 tests completed in 97301 milliseconds, with 2 failed, 2 skipped, and 0 todo.
210 assertions of 217 passed, 7 failed.

While the tests are running, the page becomes more and more unresponsive while appending output items. 24280 only represents the immediate children, the full child tree contains 146780 nodes.

> const tests = document.querySelector('#qunit-tests');
> tests.getElementsByTagName("*").length
> 146780

Solution?

  • actually remove child item when it passes

norender-example

@gabrielcsapo
Copy link
Copy Markdown
Contributor Author

@stefanpenner @trentmwillis sorry for the delay, but this is actually removing divs instead of hiding them when hidepassed is enabled.

@gabrielcsapo gabrielcsapo force-pushed the hidepassed-should-remove-test-item branch 2 times, most recently from cecac93 to bb94a7c Compare September 25, 2018 22:40

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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

There's only one item being rendered because all the test name are the same. Is this intentional?

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.

Well there should be 7 divs realistically, only one should exist as it is the current one.

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.

Fixed in f64b5a1.

@gabrielcsapo
Copy link
Copy Markdown
Contributor Author

@trentmwillis would you might checking this out again? 😄

@gabrielcsapo gabrielcsapo force-pushed the hidepassed-should-remove-test-item branch from bb94a7c to 9615597 Compare September 28, 2018 22:52
@jackson-dean
Copy link
Copy Markdown

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.

@platinumazure
Copy link
Copy Markdown
Contributor

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.

@jackson-dean
Copy link
Copy Markdown

jackson-dean commented Oct 2, 2018

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.

@gabrielcsapo
Copy link
Copy Markdown
Contributor Author

Yeah it is basically a dead code path, since we attach a new dom node when a test is initialized anyway

@gabrielcsapo gabrielcsapo force-pushed the hidepassed-should-remove-test-item branch from 05e9bb9 to 609c846 Compare October 2, 2018 20:46
Copy link
Copy Markdown
Member

@trentmwillis trentmwillis left a comment

Choose a reason for hiding this comment

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

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.

@trentmwillis
Copy link
Copy Markdown
Member

Note waiting until I get a response to the question above ^ to merge this

@gabrielcsapo
Copy link
Copy Markdown
Contributor Author

@trentmwillis how would we merge a document fragment with a document fragment?

hidden-tests <-> non-hidden-tests -> ol

This would mandate we worry about currently running tests and make sure we don't merge during a dirty dom state, right?

I don't know if optimizing the use case of toggling between succeeded and non-succeeded cases should be done in this either.

@rwjblue
Copy link
Copy Markdown
Contributor

rwjblue commented Oct 9, 2018

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

@trentmwillis
Copy link
Copy Markdown
Member

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.

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 trentmwillis merged commit 43a3d87 into qunitjs:master Oct 9, 2018
@stefanpenner
Copy link
Copy Markdown
Contributor

@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

@trentmwillis
Copy link
Copy Markdown
Member

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.

@gabrielcsapo
Copy link
Copy Markdown
Contributor Author

thank you @trentmwillis!

@stefanpenner
Copy link
Copy Markdown
Contributor

@trentmwillis <3 <3 <3

Krinkle added a commit that referenced this pull request Jun 12, 2024
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.
Krinkle added a commit that referenced this pull request Jun 12, 2024
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.
Krinkle added a commit that referenced this pull request Jun 12, 2024
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.
Krinkle added a commit that referenced this pull request Jul 5, 2024
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.
Krinkle added a commit that referenced this pull request Jul 19, 2024
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.
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