ThrottlerTest fails on an OSX Travis box
See original GitHub issueExample run: https://travis-ci.org/square/okio/builds/526916855
Those tests are time-based which probably causes them to fail on a slow machine. Need to verify their correctness and potentially use a FakeClock
instead of real time to eliminate flakiness.
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Common Build Problems - Travis CI Docs
If that build suddenly fails too, there's a good chance, that a dependency was updated and is causing the breakage. Check the list...
Read more >Build fails and there is no error (OSX) - Travis CI Community
I am experiencing the situation where it all works on Linux, but not on Mac. There's no error message. Here is a link...
Read more >travis osx brew install --with-toolchain always times out
I was able to solve this problem by installing from a binary release. This also has the nice property that it unifies linux...
Read more >Rstan/rstantools/travis - The Stan Forums
I updated the above to include Mac OS X which Travis CI now supports. ... the following passes on travis and osx but...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
CC @bnorm
The tests seem to have the tolerance threshold, which even though seems reasonable enough still doesn’t prevent tests from failing. It also feels quite large in correlation with the expected timings (e.g. expected is 0.25 millis + threshold of 0.2 millis). Not familiar that well with the applications of
Throttler
, so I’m trying to figure out if there’s a problem with the implementation, or just imperfect test setup. If it’s the latter - we can either just increase the threshold, or do that + increase the test size, so that the existing threshold is smaller as a % of the expected timing and also harder to miss.… and so perhaps we also migrate say, 10 of the 13 tests in ThrottlerTest to ThrottlerTakeTest so we get a better balance of test execution time vs. coverage.