I made some substantial changes to the codebase.
I run all the unit tests, as usual.
A test that has nothing to do with the feature I'm working on breaks.
"Huh that's odd, let me debug that"
I set a breakpoint with the condition set so that it pauses before the test assertion goes red.

I start the debugger and.... all tests pass

Turns out it only happens like 500/10000 times....

This will be fun

Oh the algorithm had random input from 0..360

But the rest checked if the output was >0 at given points

Well this was simple, I feared for the worst (undefined behavior)

@LotsOfCaffeine Grats.

@LotsOfCaffeine or race condition

@Lensflare oh those are also fun

we tend to test the snychronous components on their own. Multithreaded stuff get dedicated, very complex tests. Everything that isn't strictly part of the multithreaded functionality is done through dependency injection, so that in unit tests we can test the actual threading and so on.

In one test, one of the dependecies I injected had a mutex in there so that I could lock that mutex from the test to "pause" my worker. Using an atomic counter around that I could check to wait until the worker was exactly where I wanted it to be.

Literally

@IHateForALiving it wasn't that bad... it was more like

param.randomLimitLower = 0;

param.randomLimitUpper = 360;

param.randomEnabled = true;

...

...

...

EXPECT_GT(result[0], 0);

like, we could've seen this coming to be fair