Skip to content

Tests: Use closeEnough() to account for rounding differences #1275

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

Closed
wants to merge 1 commit into from

Conversation

tjvantoll
Copy link
Member

I looked into the failing test that was caused by b0e8380. At the moment, the failing test is fragile in that it is dependent on the padding-left on .ui-menu .ui-menu-item. If you play with that value (which is currently 1em) you can get the tests to pass and fail in various browsers. The previous value of .4em just happened to work. Some other values like .9em just happen to work as well. 1em doesn't, so tests are currently failing.

In addition to the rounding differences, there's also this check that conditionally adds a pixel to the menu's width. If I comment out that check the tests pass with the current padding, but I assume the check is necessary.

The rounding error and the conditional check each have the ability to throw the test off by a pixel, therefore I switched the test to use closeEnough() to account for this. It's not ideal, but I can't think of a better way of handling this.

cc @fnagel, @jzaefferer, @tcrowley

Selectmenu's test suite broke with b0e8380, which changed the padding
used by the menu widget. Selectmenu conditionally adds pixels to the
menu's width, and using closeEnough() accounts for that and the
rounding differences across browsers.
@jzaefferer
Copy link
Member

Sounds fine to me. We spend a lot of time with these off-by-one issues in tests that never seem to be an actual problem, so using closeEnough is sane.

@tjvantoll
Copy link
Member Author

Yeah. I should also mention that I verified that the widget's look fine in all of our supported browsers. It's just the tests.

@fnagel
Copy link
Member

fnagel commented Jun 23, 2014

I able to confirm this was only a problem in the unit tests. The mentioned
check was needed for IE10 regardless of this.

@tjvantoll tjvantoll closed this in c29b443 Jun 25, 2014
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.

3 participants