How does the Console.WriteLine Interceptors work ?

[byzantium0001]

Hi,

I've been studying the code in the repository for a few hours now and I can't really make heads or tails of how the stdout and stderr redirect is working on a per async context basis.

From what I can tell - StandardOutConsoleInterceptor gets instantiated once for each TUnitServiceProvider instance. Inside the interceptor, it calls Console.SetOut(this) on initialization. I think this means that on every new test session as generated by MTP calling into ITestFramework - this SetOut call runs. Which I think means that the StandardOutConsoleInterceptor can get overwritten by a subsequent MTP test session.

My assumption is that because there is a ConcurrentDictionary<string, TUnitServiceProvider> in the Test Framework that multiple sessions are possible simultaneously.

So - I assume that means that the actual StandardOutConsoleInterceptor doesn't matter. My best guess about how this works is:

1. Console.WriteLine accesses the StandardOutConsoleInterceptor as a TextWriter
2. Via OptimizedConsoleInterceptor - the Write access the RedirectedOut property
3. RedirectedOut property redirects to Context.Current.OutputWriter
4. OutputWriter is on either a TestContext or GlobalContext or some other context.
   1. The base class Context has the actual OutputWriter created as a concurrent string builder.
5. Assuming it is a TestContext - it has a AsyncLocal<TestContext>
   1. I think this is where the magic happens - in that this makes TestContext be uniquely accessed per async context.
   2. This somehow allows for routing the Console.WriteLine request into the OutputWriter instance that is unique to the async context.

This doesn't explain what happens when SetOut gets called again. I guess alternatively, this could be a bug that just hasn't been encountered before because it is uncommon for multiple test sessions to be active at once ?

Can anyone explain to me how this is supposed to work? What is the pathway by which a Console.Writeline in a unit test gets mapped to a TextWriter specific to a particular Test Task context ? Am I close ?

[thomhurst]

Assuming it is a TestContext - it has a AsyncLocal
I think this is where the magic happens - in that this makes TestContext be uniquely accessed per async context.
This somehow allows for routing the Console.WriteLine request into the OutputWriter instance that is unique to the async context.

Yep this is right. When tests are invoked, they will be in the correct async context that the interceptor can call TestContext.Current to get the correct context.

This doesn't explain what happens when SetOut gets called again. I guess alternatively, this could be a bug that just hasn't been encountered before because it is uncommon for multiple test sessions to be active at once ?

Yes probably. This isn't really properly supported or tested.

Can I ask what you're trying to achieve?

[byzantium0001]

OK - Thank you!

I'm trying to build a test framework for a completely different context (eg, think thermal simulations or mechanical stress simulations). I saw that you had this feature in TUnit where the Console.WriteLine gets routed per test and I wanted to figure out how that was being done so I could try and replicate it. What I found was that it was a lot more complicated than I was expecting it to be. Perhaps that is just my naïveté showing.