Consider exposing TestContext.Current static property

[Youssef1313]

We have it internal already here:

https://github.com/microsoft/testfx/blob/cd0fd625fd72bad3483d2665ae04f18fc0c65bed/src/Adapter/MSTestAdapter.PlatformServices/Services/TestContextImplementation.cs#L113

I think it's much easier to use it directly this way.

Benefits:

• No need to inject it via constructor or property
• No need to have it as a parameter on fixture methods
• Its availability via static async local will hopefully prevent users from incorrect usages of TestContext and passing it around. At any place the user needs TestContext, they can simply access the correct one (if available).
• We will keep all the old ways supported for backward compatibility, but we start documenting that it's not the recommended way.

[Evangelink]

I would prefer to have the class disappear and replaced with proper specialized context. As we discussed in the past the information available at each "step" is/should be widely different.

I think TUnit is having a TestContext.Current and some casting solution for having the various test contexts. @thomhurst what's your experience so far?

[Youssef1313]

I would prefer to have the class disappear and replaced with proper specialized context. As we discussed in the past the information available at each "step" is/should be widely different.

I thought of this, and casting was what I had in mind.

[SimonCropp]

yes please. this would make things much simpler in Verify

[thomhurst]

I think TUnit is having a TestContext.Current and some casting solution for having the various test contexts. @thomhurst what's your experience so far?

Yep I think users rely on this a lot. I do also have things like Class context, Assembly context, but I don't think they're utilised very much.

[Youssef1313]

I will consider adding in 4.1 as experimental API.