Consider adding ApartmentState as extension attribute about testfx

[AbhitejJohn]

@sbaid , @codito On second thought from the connect request isn't this something we would want in the test platform?

[sbaid]

Related connect request

[mtaron]

I think this would be super useful. There are several API like Launcher.LaunchUriForResultsAsync that require ASTA thread access. It would great to be able to call these from a unit test project -- the URI handler for a UWP app provides a good "test contract" and essentially allows UI automation of a UWP app without any additional framework. But it requires that the caller be on the UI thread, which is currently very hard to do with MSTest.

[AbhitejJohn]

@mtaron : Could that be addressed via the UITestMethodAttribute tracked by #22?
@codito : Can this be a configuration of the test platform? I'm saying so because of this comment in the connect request:
"
You can change this default behavior by adding the below key under of vstest.executionengine.x86.exe.config file located in C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow

"

[mtaron]

Yeah, UITestMethodAttribute would address this for UWP test apps, but I think being able to control which thread tests are executed on is generally useful. For example, accessing a DependencyProperty from a non-UI thread in a WPF app causes an exception.

This might a niche case, but I've been using a non-UWP test project to do performance test automation for a UWP app. In general, I find that UWP test apps are a lot harder to get running under CI, are missing a lot features like code coverage, are a lot slower, and sometime debugging them just stops working. To work around this, I've made a non-UWP test app that uses the Launcher APIs to drive a UWP app. It works pretty well! I could send you the details if you are interested. However, I am restricted to using Launcher.LaunchUriAsync (as opposed to the LaunchUriForResults), since I can't control which thread my test is running on. This reduces how much verification I can do in my tests since I don't get data back from the app about the result of the command. All that said, I bet mine is a pretty niche use case, but I saw that other customers were asking for this and wanted to add my support. :)

[AbhitejJohn]

There is now an extension built on top of MSTestV2 that helps get this done: https://github.com/saikrishnav/testfxSTAext
The nuget package for the same is at : https://www.nuget.org/packages/MSTest.STAExtensions