brandur
commented
3 months ago Just confirming, do we still have coverage on the jobs that don't run on start? We may need to look at adopting a synthetic clock for testing these reliably.
There's still plenty for non-*AfterStart tests, but yeah, these ones mostly check immediate insertion. It's not a huge stretch to think that as long as the *AfterStart functions are confirmed to get into the job bundle, they'll run.
Not against use of a synthetic clock though. It might be a little bit of work though because the synthetic clock wouldn't automatically wake the service out of its sleep loop, so you'd have to figure out how to do that.
This one continues #416. I fixed a pair of the
*AfterStarttests, but didn't look further to see that there were three more, and I guess by a stroke of luck I was running GitHub Actions at the right time and didn't encounter anymore failures (today I immediately started seeing them again when pushing).Rationale there is similar to #416:
500 ms is a short enough period that it seems to be possible in GitHub Actions for that amount of time to have elapsed by the time we check for the first set of jobs (amazing, I know, but I can't explain it any other way).
The way the tests are written, they're also very slow because each requires waiting for one of the 500 ms periods to elapse, so the minimum run time of each is 500 ms.
Technically, with the rewrites it can be argued that the test cases are checking slightly less, but IMO it's good enough, and I was having trouble thinking of alternative ways to add additional checks without raciness.
Fixes #386.