Configure `TestResults` directory from Visual Studio

[jcasale]

I have a solution with the global.json shown below, and several test projects that reference the MSTest.Sdk SDK.

{
  "sdk": {
    "version": "10.0.100-rc.2"
  },
  "msbuild-sdks": {
    "MSTest.Sdk": "4.0.1"
  },
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

When I run a test project manually using dotnet test --project xxx, the TestResults directory is created next to the test executable (although it can be changed with a testconfig.json).

When I execute the tests in Visual Studio, a TestResults directory is created in the root of the solution, next to the projects, and I am unable to configure this behavior.

Does VS need a single directory for all tests? Is it possible to change this behavior?

[Youssef1313]

When I run a test project manually using dotnet test --project xxx, the TestResults directory is created next to the test executable

This, IMO, is not a good behavior. It's something we should change soon. dotnet/sdk#52570 is a possibility here. Whenever we are about to decide the default test results directory, we should consider the new env variable set by dotnet test command.

When I execute the tests in Visual Studio, a TestResults directory is created in the root of the solution, next to the projects, and I am unable to configure this behavior.

It can be changed in Visual Studio by specifying the directory in runsettings file, but this won't work for TUnit/xunit.v3 for example as they don't support runsettings. A better idea here is to simply support testconfig.json in VS. This, however, should be reported as a Visual Studio feedback instead of being reported here in this repository.

[nohwnd]

I agree having it non-consistent is not nice. The first behavior was introduced as a quick remedy for generating test result files in predictable ways, without overwriting previous results, or overwriting them in more reasonable way.

With one common folder you need some naming to disambiguate, ideally something that is easy to determine on runtime and not random.

On the other hand having the files next to projects is not great either, it is harder to upload the artifacts, and you will end up searching for the files by wildcard anyway (reverting the benefit of not having randomness in the name).