Pure theoretically this random function could end up never adding a long wait time if random.nextBool returns false every time. Would it maybe make sense to let this method update an atomic integer every time it sets a long wait time, and then at the end of the test verify that the number of sessions that was removed is equal to that atomic integer (instead of just checking that it's greater than zero, which could in theory fail)?

That's a very good idea. Let me do this. It will make the benchmark even more precise.

I added this logic and then realised that the number of sessions removed may not be equal to the value of the atomic integer since

1. The background task may not have run and thus there may be a few dangling sessions which would be pending to be cleaned up.
2. Even if we force run a maintenance task, there may still be other reasons why the session may not get cleaned. For ex - If session hasn't breached the idle threshold.

#1 is easy to mitigate by force running a maintenance loop at the end of the test. But for #2 we will require to setup our fake clock setup and play around with the timestamps. Since we already do this for all other tests that were part of the other PR, I was thinking we can keep this benchmark close to real setup and avoid all the mocking.

What do you think?