It was one of THOSE days again, where you lose a bunch of time to a JUCE bug: https://github.com/juce-framework/JUCE/pull/1370

This morning I wasn't feeling all that energized, so I figured I'd just close out an easy TODO and play some Factorio. The easy task I picked was adding some unit tests for the new MIDI note picking GUI stuff. First I ran into some extremely weird and hard to debug crashes, which ultimately were the cause of the bug I linked (and fixed) above. I've been running into this kind of issue frequently because I appear to be the only one who is really unit testing my JUCE GUI in a sane way. The particular issue I ran into is that I tear down JUCE's GUI thread between tests to keep everything nice and hermetic. Apparently nobody else does that, or they'd likely have run into this bug.

But once I got that fixed, I discovered that my new tests were flaky, which is the worst thing! But every time I tried to reproduce the random failures, say, by running the tests 10 times in a row, they'd work perfectly. I was pulling my hair out until I finally noticed that the random failures only happened when I kicked off the tests and then alt+tabbed to another window. It turns out that some of JUCE's GUI code cares about whether the window is in the foreground. This is why I never could get the tests to fail when I was trying: I was focused on the tests and not alt+tabbing! So they'd always be in the foreground and work correctly.

My ugly solution to this problem was to just force the windows to the front. Fortunately most of the tests don't require real windows, but anything that creates a top-level dialog window does need this. So while the tests run, little windows pop up and close rapidly while parts of the GUI are being tested. Weird, but I'd rather have the code tested than not!