You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two assertions of the unchanged test suite for logarithmic scales consistently fail on my machine due to floating point inaccuracy. This only happens in Firefox, and not in Chrome. Obviously, it also does not seem happen on the CI server.
Firefox 63.0.0 (Mac OS X 10.14.0) Logarithmic Scale tests when dataset min point {x: 6.3, y: 6.3}, max point {x:78, y:78}, ticks.min: 0 and axis is "x"; expect: min = 0, max = 80, first tick = 6; should get the correct pixel value for a point FAILED
Expected 505.14327434188084 to be 505.1432743418808.
@test/specs/scale.logarithmic.tests.js:1097:54
Expected 42.93333244323725 to be 42.933332443237305.
@test/specs/scale.logarithmic.tests.js:1112:54
Possible Solution
Instead of using the toBe matcher in these lines, we could use the toBeCloseTo matcher. Since the value we are checking is a pixel obtained through the scale$getPixelForValue method, the toBeCloseToPixel matcher could also be a good choice.
Furthermore, there are multiple other lines with similar pixel comparisons that are sensitive to floating point inaccuracies. Changing these as well would make the test suite more robust.
The text was updated successfully, but these errors were encountered:
We should use toBeCloseToPixel instead of toBeCloseTo every time we check pixel values so feel free to update unit tests using this matcher. At some point, I would love to see most of these pixel tests to be converted into image based tests.
Two assertions of the unchanged test suite for logarithmic scales consistently fail on my machine due to floating point inaccuracy. This only happens in Firefox, and not in Chrome. Obviously, it also does not seem happen on the CI server.
Possible Solution
Instead of using the
toBe
matcher in these lines, we could use thetoBeCloseTo
matcher. Since the value we are checking is a pixel obtained through thescale$getPixelForValue
method, thetoBeCloseToPixel
matcher could also be a good choice.Furthermore, there are multiple other lines with similar pixel comparisons that are sensitive to floating point inaccuracies. Changing these as well would make the test suite more robust.
The text was updated successfully, but these errors were encountered: