I’ve got a legacy application that had a fragile unit test (which is really more of an integration test) that used a lot of Thread.Sleep calls to wait for events to happen.
While trying to introduce some determinism into the tests with some configurable callbacks I came across a test that is attempting to validate that given a certain input, another event doesn’t occur.
It is also using Thread.Sleep to wait for 100ms before checking to see if the callback was called, but I’m thinking that a delay in execution could result in a false positive.
I’m trying to keep the test suite snappy without introducing longer delays by increasing the value of the wait.
For the positive tests I’ve created some code barriers that get resolved through the course of the test, but I don’t see a pattern to deterministically determine that an event is not going to occur.
4
Set some variable (accessible to your unit test) when the event occurs. If the event doesn’t occur, the variable doesn’t get set; you can check for that in your unit test.
5
If the executor is a singleton then you should replace the executor returned by its getInstance() (or stored in the static INSTANCE field) with your mocking framework until you can put DI in place. That way you can monitor the task queue and be know when no more tasks are pending completion.