Hello
TimeoutAttribute(via TimeoutCommand) wraps the tests in a Task.Wait call under netcore (because Thread.Abort is no longer supported API), here:
|
if (!Task.Run(() => context.CurrentResult = innerCommand.Execute(context)).Wait(_timeout)) |
Using any of the 'flow-control' assertions like Assert.Ignore will throw their respective special-case Exception (here IgnoreException), which Task.Wait will wrap in an AggregateException, which is not handled by ValidateAndUnwrap here
|
if ((ex is NUnitException || ex is TargetInvocationException) && ex.InnerException != null) |
This will result in the test counting as full-blown failure due to unhandled exception.
This simple test will do it:
[Test, Timeout(1234)]
public void TimeoutBug()
{
Assert.Ignore("a");
}
I believe it should be safe to change ValidateAndUnwrap to handle AggregateExceptions the same way it does for TargetInvocationExceptions. It may also be beneficial to dive into the exception recursively instead of only once.
Hello
TimeoutAttribute(via TimeoutCommand) wraps the tests in a Task.Wait call under netcore (because Thread.Abort is no longer supported API), here:
nunit/src/NUnitFramework/framework/Internal/Commands/TimeoutCommand.cs
Line 102 in d8490ec
Using any of the 'flow-control' assertions like Assert.Ignore will throw their respective special-case Exception (here IgnoreException), which Task.Wait will wrap in an AggregateException, which is not handled by ValidateAndUnwrap here
nunit/src/NUnitFramework/framework/Internal/Results/TestResult.cs
Line 564 in c3caee3
This will result in the test counting as full-blown failure due to unhandled exception.
This simple test will do it:
I believe it should be safe to change ValidateAndUnwrap to handle AggregateExceptions the same way it does for TargetInvocationExceptions. It may also be beneficial to dive into the exception recursively instead of only once.