Deferred Results broken with Parallel parent test step
Environment:
Windows 10, 64-bit
OpenTAP 9.0.0
Steps to reproduce:
- Have a simple Test Step doing Deferred Results processing (I use Thread.Sleep to simulate some real processing which is not abortable). Either use TapDeferredResultsDefect.dll or compile it yourself:
using System;
using System.Threading;
using OpenTap;
namespace TapDeferredResultsDefect
{
public class DeferredResultsStep : TestStep
{
public override void Run()
{
Results.Defer(() =>
{
Thread.Sleep(10000);
Log.Info("Deferred Step also done");
});
}
}
}
- Create a Test Plan with Parallel Step as parent and DeferredResultsStep as Child
- Execute Test Plan
Actual result:
Test Plan immediately appears to be finished (Start button is again enabled), after 10sec the deferred result step finishes then in the background. This can also be seen in the log
18:34:33.972 TestPlan -----------------------------------------------------------------
18:34:33.973 TestPlan Starting TestPlan 'Untitled' on 09/03/2020 18:34:33, 2 of 2 TestSteps enabled.
18:34:33.976 TestPlan Saved Test Plan XML [3.23 ms]
18:34:33.984 TestPlan PrePlanRun Methods completed [5.20 us]
18:34:33.984 TestPlan "Parallel" started.
18:34:33.984 TestStep Starting 1 child steps in separate threads.
18:34:33.984 TestPlan "Parallel \ DeferredResultsStep" started.
18:34:33.984 TestPlan "Parallel" completed. [360 us]
18:34:33.984 TestPlan Test step runs finished. [464 us]
18:34:33.990 Summary ------ Summary of test plan started 09/03/2020 18:34:33 ------
18:34:33.990 Summary Parallel 360 us
18:34:33.990 Summary DeferredResultsStep 0.00 s
18:34:33.990 Summary --------------------------------------------------------------
18:34:33.990 Summary -------- Test plan completed successfully in 11.2 ms ---------
18:34:43.985 TestStep Deferred Step also done
18:34:43.985 TestPlan "Parallel \ DeferredResultsStep" completed. [10.0 s]
Expected result:
Test Plan should only finish, once the deferred processing is done, even if it is a child of a parallel step. This potentially broke because of fixing #288 (closed).
Other remarks:
When attaching a debugger, you also notice an exception which is probably not expected:
