dotnet-test-nunit icon indicating copy to clipboard operation
dotnet-test-nunit copied to clipboard

Is there a way to specify TestResult.xml location?

Open iluzyanin opened this issue 9 years ago • 9 comments

Currently, after running dotnet test, the result of test run is stored in current directory in TestResult.xml. Is there a possibility to somehow specify the folder where to store the xml? For example, xUnit provides -xml flag, which does exactly this, e.g. dotnet test -xml reports/TestResult.xml.

One workaround is to start dotnet test from "reports" folder, so it would save result xml there, but I was just curious if there is a straight way to do this?

iluzyanin avatar Jan 17 '17 15:01 iluzyanin

@iluzyanin Use the work parameter, like this:

dotnet test --work:"mypath/myresult.xml"

Reference: https://github.com/nunit/dotnet-test-nunit/blob/1f4e95e66aa3394d55272143a456f685c9b7b423/src/dotnet-test-nunit/CommandLineOptions.cs#L267

anderaus avatar Jan 17 '17 15:01 anderaus

Awesome, that worked! Thanks! BTW what command (if any) should I run to see all that options available? I mean not in a csharp file :)

iluzyanin avatar Jan 17 '17 15:01 iluzyanin

I couldn't find any params/commands doing that so I guess for now the only way to discover these is to look through the source code.

anderaus avatar Jan 17 '17 15:01 anderaus

Unfortunately this doesn't work anymore. --resultxml (Reference) doesn't work neither.

It is hard to maintain the overview by all the recent changes in dotnet core (project.json -> MsBuild amongst others), but this should be summarized in https://github.com/dotnet/cli/issues/3114 and https://github.com/Microsoft/vstest/issues/786.

Is there any workaround, am I'm missing something, or do we have to wait until dotnet-cli fixes this?


Version Infos

Item Version
NUnit 3.7.1
NUnit3TestAdapter 3.8.0
Microsoft.NET.Test.Sdk 15.0.0
.NET Command Line Tools 1.0.4

gfoidl avatar Aug 07 '17 13:08 gfoidl

@gfoidl you can no longer specify a result file. The only workaround is to specify a VSTest result file, see nunit/nunit3-vs-adapter#323

rprouse avatar Aug 08 '17 19:08 rprouse

I'm desperately trying to produce parseable test output on log4net with jenkins. I've tried plenty of command arg combinations and am asking for help now. The assemblies are built and tested with dotnet version 1.1.0. The test project is stored in a subdirectory named "netstandard/log4net.tests/log4net.tests.csproj" and the test run is triggered basically with:

cd netstandard/log4net.tests
dotnet test

What options do I have to add in which combination to make output files in either trx or nunit xml format? XUnit can parse them both and I pretty much don't care any longer which format they are. It just has to work somehow.

dpsenner avatar Nov 11 '17 01:11 dpsenner

@dpsenner I assume you are referring to https://github.com/apache/logging-log4net/blob/develop/netstandard/log4net.tests/log4net.tests.csproj

Since you are using the new csproj format, switch to using the NUnit 3 test adapter instead of this adapter. Using that should allow you to specify a VSTest (TRX) result file as per nunit/nunit3-vs-adapter#323. I'm actually surprised that tests even work with the combination you have in your project file 😄

See https://github.com/nunit/docs/wiki/.NET-Core-and-.NET-Standard

rprouse avatar Nov 11 '17 13:11 rprouse

Thanks @rprouse, with your help I was able to make this work. It lolks like the tests were not executed at all up till now. To make it work I had to bump a few of the dependencies to the core implementation of netstandard. I blindly assume that it's not going to become an issue. I still have to record the test results in another file because I would like to save it along with the other build artifacts. So everyone downloading a nightly build can evaluate the build quality. But as of now I see a light at the end of the tunnel. Without your insights this would probably have consumed a lot more time! With this we are approaching also a state where we can add netstandard-2.0 as a target. You've earned a lot kudos for your work and help.

dpsenner avatar Nov 12 '17 07:11 dpsenner

@dpsenner glad we could help. Keeping up with the changes to .NET Core and Standard has been a huge pain for everyone and the old documentation in the Googleverse doesn't help. I think things have finally settled down with 2.0, so things should be improving.

rprouse avatar Nov 12 '17 13:11 rprouse