Open bgrainger opened 6 months ago
I found the solution in the release notes: dotnet test -c Release -p:TestTfmsInParallel=false
It might be nice to have this be a bit more discoverable with a "top level" option like dotnet test --no-parallel-tfms
but perhaps just listing core MSBuild properties that affect test running in the dotnet test documentation would be sufficient (once .NET 9 ships).
@baronfel,
This seems like a great candidate for a doc change. I do also think it would be nice to have a top-level option for this, but it's a little lower priority to me since we do have a solution albeit one that's a little hard to find. Who would be a good contact on the docs team?
@gewarren would be my go-to for a docs contact
@tdykstra owns those docs, I believe.
I'll update the dotnet test article.
Thanks everyone! I'm going to leave this open to track making a top-level option, but with that doc update, I think this is pretty low priority now.
(Sorry if this is not the right place to report this issue, but I believe it started after installing .NET 9.0.100-preview.2.24157.14.)
Describe the bug
In an xUnit test project with
<TargetFrameworks>net462;net481;net6.0;net8.0;net9.0</TargetFrameworks>
,dotnet test -c Release
now runs the tests from the five test assemblies (for the different target frameworks) in parallel.This parallelism would normally be a welcome change, but in this case, they are integration tests that all target a shared database server. Consequently, changes made by one running integration test can modify the shared environment and cause a test in a different process to fail.
I could refactor these tests to use a unique database per run but (a) there may be users affected by this bug who can't avoid using shared resources, and (b) I'd prefer to just fall back to running the tests sequentially (since the database Docker container being used by the tests isn't powerful enough to service five concurrent unit tests projects anyway).
To Reproduce
dotnet test -c Release
Exceptions (if any)
Various test failures based on how concurrent tests interact with each other.
Other
I looked at https://github.com/dotnet/sdk/issues/10178 but it's pretty old and not sure if describing the same problem.
I ran
dotnet test --help
but didn't see a command-line argument that would control parallelism.I didn't check if this is an xunit-specific problem; I only suspect it's related to
dotnet test
having only observed the new behavior in .NET 9 Preview 2 SDK.Further technical details