Tests that sometimes fail
We&#x27;ve had a couple of cases of flaky tests failing builds over the last two years at my company. Most often it&#x27;s browser &#x2F; end-to-end type tests (e.g. selenium-style tests) that are the most flaky. Many of them only fail in 1-3% of cases, but if you have enough of them the chances of a failing build is significant.<p>If you have entire builds that are flaky, you end up training developers to just click &quot;rebuild&quot; the first one or two times a build fails, which can drastically increase the time before realizing the build is actually broken.<p>An important realization is that unit testing is not a good tool for testing flakyness of your main code - it is simply not a reliable indicator of failing code. Most of the time it&#x27;s the test itself that is flaky, and it&#x27;s not worth your time making every single test 100% reliable.<p>Some things we&#x27;ve implemented that helps a lot:<p>1. Have a system to reproduce the random failures. It took about a day to build tooling that can run say 100 instances of any test suite in parallel in CircleCI, and record the failure rate of individual tests.<p>2. If a test has a failure rate of &gt; 10%, it indicates an issue in that test that should be fixed. By fixing these tests, we&#x27;ve found a couple of techniques to increase overall robustness of our tests.<p>3. If a test has a failure rate of &lt; 3%, it is likely not worth your time fixing it. For these, we retry each failing test up to three times. Not all test frameworks support retying out of the box, but you can usually find a workaround. The retries can be restricted to specific tests  or classes of tests if needed (e.g. only retry browser-based tests).