3 ms·

if it makes thing flaky then it actually is a huge success because it found a bug you overlooked in both impl. and tests at least iff we speak about unit tes

• jstanley 6mo ago
  Only if it becomes obvious why it is flaky. If it's just sometimes broken but really hard to reproduce then it just gets piled on to the background level of flakiness and never gets fixed.
  • nomel 6mo ago
    To get around this, I have it log the relevant inputs, so it can be reproduced. The whole concept of allowing a flaky unit test to exist is wild and dangerous to me. It makes a culture of ignoring real failures in what, should be, deterministic code.
    • marcosdumay 6mo ago
      Well, if people can't reproduce the failures, people won't fix them. So, yes, logging the inputs is extremely important. So is minimizing any IO dependency in your tests. But then that runs against another important rule, that integration tests should test the entire system, IO included. So, your error handling must always log very clearly the cause of any IO error it finds.
• tremon 6mo ago
  Burma-shave
• yxhuvud 6mo ago
  This will often break on stuff like daylight saving changes, while almost as often you don't give a rats ass about the boundary behaviour.
• jamesfinlayson 6mo ago
  I remember having a flaky test with random number generation a few years ago - it failed very rarely (like once every few weeks) and when I finally got to fixing it, it was an actual issue (an off by one error).