CurrentContext.Result.Outcome.Status is inconclusive in TearDown if Timeout attribute is used in 4.x

[gboucher90]

Hi,

I know timeout attribute is deprecated in 4.x but it still seems to be a regression compared to 3.x.
It seems when using the Timeout attribute then TestContext.CurrentContext.Result.Outcome.Status is reported as Inconclusive in the Teardown method while it used to be reported as Passed before.

Example:

        [Test, Timeout(20_000)]  // Non Ok status will be Inconclusive
        public async Test_Timeout() {
              await Task.Delay(10_000);
              Assert.Pass();
        }

        [Test, CancelAfter(20_000)] // Ok status will be Passed
        public async Test_CancelAfter(CancellatonToken ct) {
              await Task.Delay(10_000, ct);
              Assert.Pass();
        }

        [Test ]  // Ok status will be Passed
        public async Test() {
              await Task.Delay(10_000);
              Assert.Pass();
        }
        [TearDown]
        public async Task Cleanup()
        {
                Console.WriteLine($"Test status = {TestContext.CurrentContext.Result.Outcome.Status}");
        }

Thank you!

[manfred-brands]

We know why it does this, but are working on a better solution to support non-cooperative Timeout support for .NET 8.0

[stevenaw]

@manfred-brands I don't think the fix from #4692 would cover this. I'm not sure if I'd have time to look at this one, but if I did I can try the IsolatedContext approach you had suggested in that PR

[stevenaw]

@gboucher90 These are shorter term fixes until the better solution for NET8+ can be completed.

[manfred-brands]

@stevenaw The separateContext was introduced for #4297. The main reason was:

As the thread running the test cannot be stopped on .NET Core, it eventually will overwrite the test result.

To prevent this I had introduced the separateContext.

But as discussed for #4692 I didn't set the TestExecutionContext.CurrentContext.

I created a PR to do this now.

[gboucher90]

Wow thanks a lot @manfred-brands & @stevenaw for looking into this so quickly and pushing a fix already :) That's greatly appreciated!