Parallel TestContext output is not set to the correct test

Description

When outputting text via TestContext and running the tests in parallel, the output is not set to the correct test

Steps to reproduce

Have multiple classes which output text and check the resulting trx file. Note: Running the tests via Visual Studio does not seem to produce this, but when running the dotnet command manually dotnet test MSTest_TestContextIssues.dll -l:trx;LogFileName=TestResults.xml

Expected behavior

The output is set to the correct test

Actual behavior

My test is simply outputting the class name and the test method and in a single test it has outputted:

        <StdOut>Std: UnitTest4 - TestMethod1&#xD;
Std: UnitTest7 - TestMethod1&#xD;
Std: UnitTest5 - TestMethod1&#xD;
Std: UnitTest8 - TestMethod1&#xD;
Std: UnitTest6 - TestMethod1&#xD;
Std: UnitTest2 - TestMethod1&#xD;
Std: UnitTest3 - TestMethod1&#xD;
Std: UnitTest1 - TestMethod1&#xD;
&#xD;


TestContext Messages:
TC: UnitTest1 - \u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000TestMethod1\u0000\u0000&#xD;
: UnitTest7 - TestMethod1&#xD;
TC: UnitTest5 - TestMethod1&#xD;
TC: UnitTest6 - TestMethod1&#xD;
TC: UnitTest8 - TestMethod1&#xD;
TC: UnitTest2 - TestMethod1&#xD;
TC: UnitTest3 - TestMethod1</StdOut>

Environment

The fix provided for v2.2.9 seems to have fixed it for std output when running the tests in Visual Studio.

But the issue still persists when running with dotnet test

Refer sample project here

[Evangelink]

Hi there,

I just looked at the code to understand what’s going-on and how things are setup and I understand what’s the issue. While the fix is not technically super challenging it risks to impact lot of places in the codebase. I will try to confirm if I can avoid touching any public API in this case we could work on it for some 3.xx release otherwise we will have to postpone it for a 4.xx release.

Technical note: We need to replace the various stream globally and only once with a custom class. Before the call of any test, we would use AsyncLocal feature to set a unique identifier (test ID?) that would be used in the custom class to classify received (for example adding to a ConcurrentDictionary). At the end of the test execution, we can retrieve the entry and add it to the test result.

[Evangelink]

@StevenDenman @krijohan I have managed to reproduce the issue. Thank you!