TestContext does not flow in async method

[Suremaker]

Example tests recreating issue:

[TestFixture]
public class TestContext_async_issue
{
    [Test]
    public async Task TestContext_Out_should_flow_with_async_execution()
    {
        var expected = TestContext.Out;
        await Task.Yield();
        Assert.AreSame(expected, TestContext.Out);
    }

    [Test]
    public async Task TestContext_CurrentContext_should_flow_with_async_execution()
    {
        var expected = TestContext.CurrentContext;
        await Task.Yield();
        Assert.AreSame(expected, TestContext.CurrentContext);
    }
}

The side effect of that behaviour is that it is not possible to use TestContext.WriteLine() after await as it causes NullReferenceException.

Tested with NUnit 3.5.0, net46 and netcoreapp1.0

[Suremaker]

The problem is that TestExecutionContext is holding current context with [ThreadStatic] attribute (source code link).

While it works fine in scenarios where multiple tests are executed in parallel (but each in given thread at a time), in async scenarios it will not work as each method continuation may execute in other thread.
Replacement of [ThreadStatic] with AsyncLocal would be solution here, but unfortunately this class is available since .net 4.6 which is a pain for frameworks supporting older net versions :(

[rprouse]

Thanks for the analysis. It doesn't sound like it is going to be an easy fix.

[Suremaker]

For pre 4.6 there are some workarounds like:

• CallContext however it would not work below 4.5 (according to article) as well as should be replaced with AsyncLocal in >4.6
• custom implementation of SynchronizationContext however implementing it right in pre 4.5 will be difficult, as way how tasks were supporting SynchronizationContext flow was buggy - it is available since .net 2.0 however.

[jhickson]

Could the issue I reported a few days ago in #1952 be explained by this? Though there .net46 is fine - it's just .netcoreapp1.1 that is the issue.

[Suremaker]

@jhickson I think those issues are correlated to some extent. Definitely in your scenario task is being executed in another thread, so it will not share the context that has been setup for test method.

I am not sure however if fixing async/await scenarios will make your scenario working as well, as you are using TaskFactory explicitly and I do not know if it would be enough in this case.

[CharliePoole]

They are both part of a more general problem: TestExecutionContext doesn't get properly initialized if the test creates a thread outside of NUnit's control. Issue #1952 is a perfect example.

This is as well, except that there's some chance we can get control of the thread creation by using our own SynchronizationContext.

@Suremaker's analysis is correct as far as the Portable and NetStandard builds go. I used ThreadStatic in Portable because it's the only thing I could find. The desktop builds use CallContext and the now removed CF build did something else.

Since the implementations are different in each build, it's important that any comments on this problem report which build is in use.

[Suremaker]

Hello,

I made a commit on my fork that solves the issue for NetStandard1.6: Suremaker@4349f80
I imagine that similar change should be done for NET46 and above but such do not exist yet in the solution so I did not go that far.

I modified the tests slightly because I realized that second original test will always fail, so now they are as follows:

         [Test]
         public async Task TestContext_Out_should_flow_with_async_execution()
         {
             var expected = TestContext.Out;
             await Task.Yield();
             Assert.AreSame(expected, TestContext.Out);
         }

         [Test]
         public async Task TestExecutionContext_CurrentContext_should_flow_with_async_execution()
         {
             var expected = TestExecutionContext.CurrentContext;
             await Task.Yield();
             Assert.AreSame(expected, TestExecutionContext.CurrentContext);
         }

Later I will check if this change will cover the issue with netcoreapp1.0 as right now I really do not know if in this scenario a portable (broken) version is used or netstandard1.6.

When proven working and you would be happy with solution I can make a pull request.

[rprouse]

#1973 fixed this for .NET Standard

[Suremaker]

I wanted to check if there is the new release date know for this fix yet?

[CharliePoole]

The merged PR fixes the problem for .NET Standard only. The issue is still open with respect to all other platforms. We would welcome people who use .NET Standard trying it, by getting the latest development build from our MyGet feed at https://www.myget.org/F/nunit/api/v2. Please let us know if it works for you!

In the normal course of events, this fix will be in the next release. Releases are scheduled quarterly and the next one (3.7) is due on March 10 - actually a bit earlier than the end of the quarter. For critical fixes, we do interim releases (3.6.1, 3.6.2, etc.) but we aren't treating this one as critical.

Since .NET standard support is still somewhat experimental, I'd advise you to use a dev release if you are dependent on it. I wouldn't suggest doing automatic updates of those pre-releases, since there could be a lot of thrashing involved, but keep track of what fixes are merged and update when it's useful.

[jnm2]

Yay, I just hit this with net452. There's no chance we'll be able to use netstandard soon.

What about a null check in case you're asserting without a test context? That might tide everyone over.

nunit/src/NUnitFramework/framework/Assert.cs

Lines 364 to 368 in 8ae0489

	TestExecutionContext.CurrentContext.CurrentResult.RecordAssertion(
	AssertionStatus.Failed, message, GetStackTrace());
	// If we are outside any multiple assert block, then throw
	if (TestExecutionContext.CurrentContext.MultipleAssertLevel == 0)