On the other hand, I think I can re-enable checking if the event thread has finished and generating
EventThreadStillProcessingErrors in the “update”
Runnable that sets the test thread group the event thread uses, at least in certain cases.
It is possible that test A has generated the
EventThreadStillProcessingError by putting a long
Runnable aRunnable on the event queue. When test B starts executing, it puts an update
Runnable updateB on the event queue, but it doesn’t execute yet.
aRunnable finishes now and
updateB executes while test B is still running, we can enable checking the event thread again. The event thread has “caught up” with the tests, so to speak.
If, on the other hand, test B finishes before
aRunnable finishes, then test C will begin and enqueue an update
Runnable updateC. Now
aRunnable finishes and
updateB executes. Here we clearly don’t want to enable checking, because test C is already executing.
So, if the test’s thread group and the new thread group for the event thread are identical, we can re-enable checking the event thread, because that means the event thread has caught up sufficiently.