Hacker News Reader

Comment by mixedCase | Hacker News Reader

> During day-to-day development, the important bit isn't that there are no failures. The important bit is that there are no regressions.

And that's why we test and why tests shouldn't be allowed to fail.

Just because the scenarios described make testing hard does not change reality of what makes tests valuable.

If pre-existing failures are halting the production pipeline and you don't like it, switch off trunk based development and see if you like the waits and constant rebasing in large projects/teams. But don't eff with the bloody tests!

View on HN

when the codebase gets large enough you need to allow some tests to "fail" but really I mean you need a way to quickly mark a failing test as flakey so the author can fix it while everyone else can get on with their day and merge code.

At $dayjob this works well, if your CI comes up red with some unrelated test failing, you can mark the test as flakey in the UI and CI will allow your code to merge and a Jira ticket will be created for the test owner to fix their test (and it will be disabled for future test runs)

I think for small to medium projects, you can have all tests succeed but once the repo is large enough / has frequent enough changes, flakey tests are bound to slip in.

That sounds like it works, but shouldn't flaky tests be detected by frequent automatic test suite runs?

yeah I think the system is a combination, although I'm not sure the intricacies tbh

I've heard google does something fancier where they take a test, run it a bunch after it fails to check if it's failed

I think the system at work only runs each test a couple times before giving up and marking it failed

That sounds fantastic. What tool are you describing?

It's some home grown UI glued on top of Jenkins

This is pretty much the one feature that's nice, otherwise it's like a worse version of circle/github actions

Our setup just reruns the tests a few times which sorts out flaky tests. The page then shows the most frequently failing tests so they can be properly fixed.

I think GitHub does something similar - public website tests must always pass but if you break GitHub Enterprise you get three days to fix it (or something like that - I think they had a blog post on it).

Reply on news.ycombinator.com