Save and restore the SynchronizationContext before and after each test case

[jnm2]

One of hundreds of tests is causing System.Windows.Forms.Control.CreateHandle() which installs a WindowsFormsSynchronizationContext. When the test worker runs the next and that test happens to be async, the test deadlocks due to the fix for #2123 not being released yet. The problem is, even with the deadlock fix in NUnit, I don't want the next test running with a WindowsFormsSynchronizationContext.

Rather than locating the misbehaving test(s) through trial and error I'd rather have a failure or at least a warning of executing the work item caused an overall change to the thread's SynchronizationContext.Current. That would cause a nice todo list to fall out of my tests.

Or would we prefer to save and restore SynchronizationContext.Current with the other global state we save and restore?

Either way, we'd have to make sure that we take the snapshot before any ITestActions and other setups start and only compare or restore after they all tear down.

[jnm2]

Third party control's constructor is creating an internal control's handle. So how do I want to handle this: add boilerplate to a ton of tests, or have the ITestAction simply restore rather than warning?

This sort of makes me think NUnit should silently restore the SynchronizationContext by default.
Or else, maybe assert a warning with a message that if this is expected, you should mark the tests with [RestoreSynchronizationContext] which we would ship?

Since neither VS, ReSharper or NCrunch UIs display warnings, maybe a failure? Or is that too much in the way?

[jnm2]

@sharwell Since you've worked in this area, I'd love to know what would your ideal would be in a test framework.

[sharwell]

Or would we prefer to save and restore SynchronizationContext.Current with the other global state we save and restore?

⬆️ This

[jnm2]

@sharwell Thank you!

@nunit/framework-team I'm thinking we should save and restore the SynchronizationContext in TestExecutionContext. This fits our theme of working more smoothly with SynchronizationContexts. Any thoughts before I retitle and put this in for 3.11?

[jnm2]

Want to do this after #2818.

[jnm2]

Also have instances where TestCaseSource is creating objects which change the synchronization context. Need to make sure this is addressed, as well as any other discovery-time execution of user code.

[rprouse]

@jnm2 moving this out of the 3.11 milestone.