Hmm. I absolutely hate tests that fail when nothing is wrong. My best tool is to reduce the strength of the assertion (at the most extreme end, turn it into a smoke test: run the code and assert nothing other than it doesn't explode). If it's based on something volatile, I might generate the data or assert "it seems to have the things I expect" rather than "it matches some fixture".
For flaky tests, it's a question of why they're flaky. If it's some async thing, maybe add a callback so the assertion doesn't happen until the async thing has occurred.
Fortunately, I've not been on a project where a consistently failing test is an acceptable thing to have.
But yeah, I've deleted tests that fail / removed environments that cause the tests to fail, when I can't easily get into that environment to test them myself, but know that they generally work (eg some specific version of the interpreter on an OS I don't have easy access to).
Yeah, I hate those tests too. Fortunately, we don't have too many of those anymore and we typically fix them quickly.
Most of our quarantined tests are legitimate failures, but the bug is a low priority. Honestly, I'd prefer not to run the test at all until the bug is fixed since we know it's going to fail. But this way we get some measure of part of our technical debt.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hmm. I absolutely hate tests that fail when nothing is wrong. My best tool is to reduce the strength of the assertion (at the most extreme end, turn it into a smoke test: run the code and assert nothing other than it doesn't explode). If it's based on something volatile, I might generate the data or assert "it seems to have the things I expect" rather than "it matches some fixture".
For flaky tests, it's a question of why they're flaky. If it's some async thing, maybe add a callback so the assertion doesn't happen until the async thing has occurred.
Fortunately, I've not been on a project where a consistently failing test is an acceptable thing to have.
But yeah, I've deleted tests that fail / removed environments that cause the tests to fail, when I can't easily get into that environment to test them myself, but know that they generally work (eg some specific version of the interpreter on an OS I don't have easy access to).
Yeah, I hate those tests too. Fortunately, we don't have too many of those anymore and we typically fix them quickly.
Most of our quarantined tests are legitimate failures, but the bug is a low priority. Honestly, I'd prefer not to run the test at all until the bug is fixed since we know it's going to fail. But this way we get some measure of part of our technical debt.