We encountered an issue where our tests were consuming too many resources on our build agents due to parallel execution. However, we wanted to keep the tests parallelized to reduce execution time locally. If you place a .runsettings file with parallelism enabled in the solution (.sln) folder, all solutions in that folder will automatically have parallelism enabled. You then create a buildagent.runsettings file, specified in the build pipeline, that executes tests sequentially.

The problem with this approach is that the auto settings apply to all solutions in the folder, which didn’t work well for us. We have legacy solutions that can’t run in parallel. So, my approach was to instead use an attribute in the test assemblies that supports parallelism:

[assembly: Parallelize(Workers = 0, Scope = ExecutionScope.MethodLevel)]

This enables parallelism locally and uses all available logical CPUs. For the build agents, I created a custom buildagent.runsettings file:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <RunConfiguration>
    <MaxCpuCount>0</MaxCpuCount>
  </RunConfiguration>
  <MSTest>
    <Parallelize>
      <Workers>1</Workers>
      <Scope>MethodLevel</Scope>
    </Parallelize>
  </MSTest>
</RunSettings>

This setup overrides parallelism when called with dotnet test –settings buildagent.runsettings on the build agents.