STA for Fixture Collections about xunit.stafact HOT 5 OPEN

Maybe. I'm not sure if xunit gives an individual test attribute like [StaFact] control over how fixtures are initialized, given fixtures are shared across tests that may use different attributes, I'm not sure that would even make sense.

Maybe the better approach is for your fixture to not initialize itself, but rather leave it to the first test to call into it (from the STA) and then it can lazily initialize.

from xunit.stafact.

This is a issue to me too. I have some heavy initialization in the fixture collection that must be run on the same STA thread as all tests. One solution is to make an API available to let the fixture collection to schedule code in the STA thread created for [StaFact]

from xunit.stafact.

Each StaFact runs on a new STA thread (which is required for concurrent test execution.)
If you have data structures that remember the thread they were created on and must be accessed only from that thread, that's a more strict requirement than StaFact provides, since it is only designed to run the test on an STA thread. There's no concept of the STA thread.

from xunit.stafact.

#54 tracks a similar requirement. So we might devise something clever here.

from xunit.stafact.

Each StaFact runs on a new STA thread (which is required for concurrent test execution.)

If you mark a test class as a [Collection()] all StaFact tests seem to run on the same thread.

But when trying to use multiple classes with the same Collection name to share a fixture, the collection Fixture isn't constructed inside an StaThread.

from xunit.stafact.