Improvements to dotnet-test docs

[mairaw]

We had several good questions on the dotnet test topic that are good indicators on how we can improve that topic.
This issue has some of the questions and the answers I got from the devs.

• Are there any examples of using "--settings"?
Our docs simply repeat what the CLI help says: “Settings to use when running tests.” It’d be good to add an example to that, what’s the file format expected, file extension, which settings you can use, etc.
Is this topic (https://docs.microsoft.com/en-us/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file) relevant to the --settings? It’s VS specific but it does show how to customize the .runsettings file. Would that be an appropriate link?
Please see https://github.com/Microsoft/vstest-docs/blob/master/docs/configure.md
@codito my suggestion would be to add this topic to the docs here.

• How can I pass additional arguments to the test runner (e.g. XUnit) such as the -nunit parameter to format the output? I see that dotnet run now allows -- to separate arguments but that doesn't seem to apply to dotnet test?
This is supported via runsettings as command line arguments. See item 3 here. User can modify behavior of the adapter from command line. Please note that the architecture in newer dotnet test (1.0 Preview 2+) is different than the ProjectK one. Later versions of dotnet test don't call dotnet-test-xunit.exe directly, instead they work with adapters. For this specific ask, I don't think there is a xml reporter available for nunit yet (nunit/nunit3-vs-adapter#215). I've created an issue for a logger extension here: https://github.com/Faizan2304/LoggerExtensions/issues/7

• Is there a way to set the location for where the tests are run?
.NET Framework tests are run from the bin/debug folder, but for the dotnet test projects, they are run from where ever I run the DOTNET TEST command. This makes it awkward to copy files that should be available for the tests.
For instance .... if I run am in the solution root folder and run "DOTNET TEST PROJECT.UNITTESTS/project.json" ... the tests will when executing read as default, from the solution root folder. If I run the test from within VisualStudio, I am IN the UnitTest project folder ...
Are there any "undocumented" properties that I can set, for the tests to always run in - for instance, the output folder, as in .net fw?

I am not sure if dotnet test is doing something special here, but msbuild always runs in the context of the project being executed. You mention project.json above, so I wonder if this is coming from people using the old tooling, in which case, we won’t really support improvements there.
In csproj world, dotnet test and vstest always run tests from output directory. User can use AppContext.BaseDirectory to consume test assets in the output directory.

• How can I run a single specific test?

You can do that using dotnet test --filter=”FullyQualifiedName=<test_name>” which will match tests with exactly the fullyqualified name or dotnet test --filter=”FullyQualifiedName~<test_name>” which will match any tests that have that name.
Please see https://github.com/Microsoft/vstest-docs/blob/master/docs/filter.md. Also dotnet test --filter mytest is a shortcut for dotnet test --filter FullyQualifiedName~mytest.

• It is not clear how to test a class library. What frameworks and testrunners are supported. There are no examples of actual tests!

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 61ca4064-7481-a263-60fc-c70127f2ad16
• Version Independent ID: 2878af44-8208-7bd8-46d4-3acda3e82ce0
• Content: dotnet test command - .NET Core CLI
• Content Source: docs/core/tools/dotnet-test.md
• Product: dotnet-core
• GitHub Login: @mairaw
• Microsoft Alias: mairaw

[guardrex]

Cross-reference: Tracking NUnit progress for dotnet/docs on #1785, which links thru to NUnit-.NET Core adapter tracking on nunit/nunit3-vs-adapter#297.

[BillWagner]

We've delayed this several times, so I upped the priority for visibility.