Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In Chrome, the UI reports more precision than is useful #1678

Closed
Krinkle opened this issue Feb 23, 2022 · 0 comments
Closed

In Chrome, the UI reports more precision than is useful #1678

Krinkle opened this issue Feb 23, 2022 · 0 comments

Comments

@Krinkle
Copy link
Member

Krinkle commented Feb 23, 2022

In Firefox:

16 tests completed in 121 milliseconds, with 0 failed, 0 skipped, and 0 todo.

In Chrome:

16 tests completed in 124.19999992847443 milliseconds, with 0 failed, 0 skipped, and 0 todo.

Tell us about your runtime:

  • QUnit version: 2.18.0
  • Which environment are you using? (e.g., browser, Node): browser
Krinkle added a commit that referenced this issue Mar 31, 2022
The run duration, test duration, and assert offset time were still
measured with Date.now(), and with a fallback that is no longer needed
since Date.now() is available in all supported browsers (IE9+).

In Firefox, Date.now() is generally a whole number. In Chrome, this
has recently changed to expose fractions. This resulted in a UI
regression where the QUnit runner exposes quite long decimals that
aren't useful.

Since perf.now() always has detailed fractions, avoid this regression
spreading to Firefox and round the numbers in the UI.

While at it, improve details of test failures from the
internal html-reporter test.

Fixes #1678.
@Krinkle Krinkle self-assigned this Mar 31, 2022
Krinkle added a commit that referenced this issue Apr 18, 2022
Follows-up b70af72, which corrected this in the UI, but this
means any plugins and integrations reporting `details.runtime` are
still affected by the needless precision.

This affects:
* `QUnit.log`, `QUnit.testDone`, `QUnit.moduleDone` and `QUnit.done`.
* `on('testEnd')`, `on('suiteEnd')`, and `on('runEnd')`.

I was initially cautious about this as I worried that perhaps
consumers would accumulate these and then become increasingly less
accurate in large test suites where perhaps most leaf nodes round to
0ms. However I have no such case in practice. Generally, for total
times the reported totals can be, should be, and are being used.

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

No branches or pull requests

1 participant