The run function in runner.py assumes a specific order of messages from the queue. If the test loader in poolRunnergot an unrunnable object, it would attempt to report it, but would never actually put the result in the queue, so the run function would fail because it assumed it would get a result instead of the sentinel None from the cleanup function.
I think this is because of the changes introduced in efb54c0, which moved from putting the result object into the queue in the stop_callback of the ProtoTestResult to the finalize_callback with the new finalize method which would only be called from the test's run method. These changes correctly put the result object into the queue when the test was not able to run, but did not account for the need in this abnormal case.
Coverage remained the same at 100.0% when pulling f91cd8225de359d71e060aeee3d25d46abf895e7 on skeggse:patch-1 into 7f4655af690fede737b1cb0dd1cda0bc9f794e60 on CleanCut:master.
The
run
function in runner.py assumes a specific order of messages from the queue. If the test loader inpoolRunner
got an unrunnable object, it would attempt to report it, but would never actually put the result in the queue, so the run function would fail because it assumed it would get a result instead of the sentinelNone
from thecleanup
function.I think this is because of the changes introduced in efb54c0, which moved from putting the result object into the queue in the
stop_callback
of theProtoTestResult
to thefinalize_callback
with the newfinalize
method which would only be called from the test'srun
method. These changes correctly put the result object into the queue when the test was not able to run, but did not account for the need in this abnormal case.