vstest.console.exe execution model and isolation behaviors

Question

I'm trying to determine the considerations that should be made when writing tests that are going to run under vstest.console.exe.

Example 1: Let's say that I have two tests both of which rely on MyClass.Singleton.Counter having a value of zero. Now let's say that we hire a new intern that inadvertently increments that value in a test that he writes. If this new test runs before the older two unit tests. Those two unit tests would fail if the tests are run in the same process (and nothing resets the counter value).

Example 2: Let's say I have two integration tests that hit the same DB. Both of these tests record the value of a counter as it exists in the DB, increment the counter, and then read the counter from the DB, asserting that it's value is 1 higher than when originally read. If both these tests run in parallel, we have a race condition.

With the end goal of trying to understand the considerations developers should keep in mind when writing tests that will run under vstest.console.exe specifically, what is its execution model?

NOTE: I'm not interested in best practices, only in understanding the execution model of vstest.console.exe in the ways that affect the outcomes of tests.

Relevant Considerations:

1. If project1.dll and project2.dll are passed to the console, and each has dependencies on conflicting versions of dependent assemblies, how will the project test files execute successfully?
2. Is each test file (i.e., dll) given its own process?
3. Is each test file (i.e., dll) given its own AppDomain within a single process?
4. What is the current working directory under which each test file will be executed?
5. Will the tests be executed serially or in parallel?
6. Is the test execution order deterministic?
7. How much control do different test adapters have over the relevant behaviors?
8. What are the default behaviors when no .runsettings file nor test adapter are specified?

Relevant Background Information:

(1) The vstest.console.exe documentation for /InIsolation states that it "Runs the tests in an isolated process."

I would infer from the above that a single process is created in which ALL test files passed to the test runner will execute, but that may not be accurate.

(2) vstest.console.exe can take multiple test "files" on the command line, which are DLLs that may reference different projects in different directories.

(3) By providing a *.runsettings file, a test adapter can be used to execute the tests.

Sweatt

If your test is dependant on a specific setting, why not check it before running the test? If this setting is the result of previous operations, you can implement an exception or warning. – Lys

2 - 4 could be tested relatively easy for with ProcessExplorer. Regarding the all points raised I'm sure you are aware, that this is all undocumented behaviour and could change; Poking around in the sources might help. – Buxom

It's a year later and no answer, but I really need to know what the AppDomain behavior is of vstest.console running multiple assemblies, as I'm getting AppDomainUnloadedExceptions, but only under specific conditions. – Ramsdell