Closed aidanjryan closed 5 years ago
The symptom on the test failure is:
Expected: "test output"
Action: "output from another test....test output"
Debugging dotnet test
with VSTEST_HOST_DEBUG=1
shows that in parallel test execution, the shared use of System.Console (with SetOut redirecting to the test's StringWriter), the last-one-in wins and gets all of the output of any in-progress tests that hadn't yet written their output at that moment.
I think behavior changed here because I introduced a new async test which must have subtly shifted the order / parallelism of test execution.
Any ideas about the best way to preserve parallel test execution but prevent the race? Can the [Collection] attribute be applied test-by-test to those that verify Console output?
@aidanjryan I'm so sorry I dropped the ball on this one. I'll take a look tomorrow and try to get this addressed. I just happen to be doing some Oakton work for the first time in ages and noticed this again:/
@jeremydmiller No worries! I had it on my back burner too, I meant to try a couple of ideas for dealing with test parallelism.
Got it with a merge. Thank you @aidanjryan
We need to do some setup in the DI container based on the input object, before the command is built by DI. This seems like a straightforward way to do it, hope this is useful.