See this document for an in depth analysis of the real use case scenario that lead to that spike.
The goal is to call dotnet test at solution level ( dotnet test
) and run tests for each assembly sequentially.
Tests inside each assembly could run in parallel, we know how to serialize them with collections, this is not interesting now.
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-test
There are 3 projects
-
Common: here we have a common sequential collection definition to prove it cannot be shared across projects.
XUnit.Tests.UnitTest1
uses its local sequential collection but you can change the namespace to point to the Common one and see that it generates an error. -
XUnit.Tests: an assembly with some long running tests. One of them FAILS to check that use case.
An
xunit.runner.json
configured to be copied at runtime. -
XUnit2.Tests: an assembly with some long running tests.
An
xunit.runner.json
configured to be copied at runtime.
-
Tested a common collection definition to relate tests across assemblies, this can't be done and the documentation prove that.
-
Tested xunit.runner.json with
parallelizeAssembly=false
-
Tested xunit.runner.json with
maxParallelThreads=1
-
Tested
dotnet test -- xunit.parallelizeAssembly=false
-
Tested
dotnet test --settings additionalargs.runsettings
with a.runsettings
available in the solution root
See the open PR and choose a viable solution between them.