There are two different abort scenarios.
Scenario 1 - Programatically abort Test Plan Execution from TestStep
If you want to programmatically abort a Test Plan execution from a TestStep
you can call the PlanRun.MainThread.Abort()
method.
Scenario 2 - Handling User Abort requests from the GUI in a TestStep
If you have a step that takes a long time to execute, you can call the OpenTap.TapThread.ThrowIfAborted()
method to check if an abort is requested during the execution of the step.
3 Likes
Correction to scenario 1:
The best way to programmatically abort a test plan from a test plan is to just throw an exception and allowing OpenTAP to handle the rest.
This will make sure that the Test Plan is stopped in a controlled manner.
@rolf_madsen @janus.faaborg
In scenario 2, sometimes my lengthy operations take place in an isolated class that does not reference OpenTAP, so the isolated class can’t call OpenTap.TapThread.ThrowIfAborted().
There’s an easy solution, just pass in PlanRun.MainThread.AbortToken to the isolated class. This works fine since PlanRun.MainThread.AbortToken is a CancellationToken, a common .NET type. Then the isolated class can call cancelToken.ThrowIfCancellationRequested(), so it will stop execution if the user has requested an abort.
4 Likes
What is the best way to abort from Resource Open()? Say you have an Instrument Resource and it cannot be opened for some reason. Also throw an exception?
Yes, then it will know that it failed to open.
1 Like
@kaushik.santhanam Regarding your correction to scenario 1, I think it depends on which verdict is preferred. If I throw an exception, the verdict is Error. If I execute PlanRun.MainThread.Abort(), the verdict is Abort.
2 Likes
I agree, if it’s an intentional abort then I use the Abort function, but if it’s an error that would cause the test plan to fail then I let it throw an exception