Does not work after migrating to csproj

[trampster]

This message is displayed:

No test discoverer is registered to perform discovery of test cases. Register a test discoverer and try again.

This is my csproj file:

 <PropertyGroup>
     <OutputType>Exe</OutputType>
     <TargetFramework>netcoreapp1.1</TargetFramework>
 </PropertyGroup>

 <ItemGroup>
     <ProjectReference Include="../Jsonics/Jsonics.csproj" />
 </ItemGroup>

 <ItemGroup>
     <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />
     <PackageReference Include="NUnit" Version="3.6.0" />
     <PackageReference Include="dotnet-test-nunit" Version="3.4.0-beta-3" />
 </ItemGroup>

[rprouse]

The new CSPROJ format officially deprecates support for the dotnet-test-* test adapters for running unit tests. Tests will be run in VS and on the command line using the old Visual Studio adapters. We haven’t converted our VS adapter to support .NET Core yet though, so the only way to run NUnit tests will be to make them self-executing using NUnitLite.

[ghost]

@rprouse Can you please give an example of how I can run my Nunit tests using NUnitLite on netcoreapp1.1?

[rprouse]

@sepidehkh I hope to write an updated blog post about how to do it soon, but in the meantime, my original .NET Core blog post should get you started. http://www.alteridem.net/2015/11/04/testing-net-core-using-nunit-3/

To make the migration easy, you can leave your tests as-is and add a .NET Core console app to be the runner. Reference your tests and use one of your tests classes as the constructor to AutoRun.

Let me know how it goes...

[ghost]

Thank you @rprouse! That fixed my problem.

[mayuanyang]

how about xunit?
<ItemGroup> <PackageReference Include="dotnet-test-xunit" Version="2.2.0-preview2-build1029" /> <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" /> <PackageReference Include="Shouldly" Version="2.8.2" /> <PackageReference Include="System.Console" Version="4.3.0" /> <PackageReference Include="TestStack.BDDfy" Version="4.3.2" /> <PackageReference Include="xunit" Version="2.2.0" /> </ItemGroup>

[rprouse]

@mayuanyang xunit works, but that isn't useful for people who prefer NUnit or have many unit tests to convert. We know that NUnitLite is not a viable solution in the long-run, but it will hopefully hold people over in the short term while we update the adapter.

[toralux]

Reference your tests and use one of your tests classes as the constructor to AutoRun.

What do you exactly mean by "use one of your tests classes as constructor to AutoRun?

Basically I use AutoRun like this, but still no tests are discovered or run:
return new AutoRun(typeof(Program).GetTypeInfo().Assembly).Execute(args, new ExtendedTextWrapper(Console.Out), Console.In);

All tests are in same assembly/project as the console-app starting AutoRun

Update: Got this in my Output-window:

An exception occurred while test discoverer 'NUnit3TestDiscoverer' was loading tests. Exception: Method not found: 'System.Xml.XmlNode NUnit.Engine.ITestRunner.Explore(NUnit.Engine.TestFilter)'.
========== Discover test finished: 0 found (0:00:00,7601484) ==========```

[csbondeson]

@rprouse I am trying to use your suggested NUnitLite setup but I need to be able to output the results preferably in the nunit2 format, is this possible? The command that I have been using in the nunit3-console.exe is "{ProjectDll} --result nunit-tests.xml;format=nunit2". Any help would be greatly appreciated.

[csbondeson]

I tried just sending those exact same args into my command line and it seemed to work so you can ignore my previous question.

I would like to know if there is any ETA on getting the VS2017 integration working.

Thank you.

[SergioLuis]

Hi,

Is there an ETA for this?

I have set up, as suggested before, a console application using NUnitLite to run my tests, but I've found out that, every time the NUnit package is restored, an empty Program class with its own Main(string[] args) method is being generated. I have not found a way to explicitly tell Visual Studio that it should use my Main method as the entry point (Visual Studio won't discover any entry point to let me choose it on the project properties!), and because the autogenerated Program class is always empty, using NUnitLite to run my NUnit tests is being a pain.

Is there at least any way to turn the autogeneration of this class off?

Nonetheless, thank you very much for your awesome framework, keep up the good work!

[taormania]

@SergioLuis I didn't find a way to turn off the autogeneration (my theory is this is an issue caused by the conversion to csproj) but all I did to solve this was create a new console application project and copy my tests in.

[CurlyFire]

Hi rprouse,

Do you have an idea as to when will this be fixed ?

Thanks

[toralux]

I just think that porting form NUnit to XUnit would be a right thing to do as this project is not very well maintained and moving very slowly comparing to the other project..

[rprouse]

@CurlyFire there is a working PR at nunit/nunit3-vs-adapter#313 and we are getting very close to being ready to do an initial release. I would suggest following that PR and it's issue nunit/nunit3-vs-adapter#297 as that is where the work is happening. The API for the adapter was changed with the latest release of .NET Core, so this project is no longer needed. If you want, you could help us test and move your project forward by using our CI feeds. I can provide info on how to do so if you are interested. Better yet, watch nunit/nunit3-vs-adapter#297 as I will likely post a quick walk-through there soon.

@toralux this project is not maintained because the test API that this project uses was dropped in favor of the old Visual Studio test API. We knew that was the plan, so stopped work on this project, but couldn't get the documentation we needed to update the other project until just before Visual Studio 2017 was released. That is why we are a bit slow to release, but I have been working nearly exclusively on enabling .NET Core support since Visual Studio 2017 was released. The xUnit project had a head start because the .NET Core team is using it and had a vested interest in making it work.

[CurlyFire]

@rprouse Great, I'll talk to my project manager if that would be a possibility that we could help you out. I was wondering, since the PR is for .Net Core support in visual studio, will I be able to run NUnit tests from the command line without using NUnitLite ?

[la-yumba]

@CurlyFire once the adapter for .Net Core is done, you should be able to run your tests with the dotnet test CLI command (as well as VS)

[rprouse]

@CurlyFire as @la-yumba says, you will be able to use the dotnet test command line, but for some reason it isn't working yet even though it is supposed to. I am looking into it though.

[toralux]

@rprouse My dotnet core nunit-tests runs like a charm now using the "NUnit3TestAdapter" version "3.8.0-alpha1", both from command-line (dotnet test) and Visual Studio 2017's Test Explorer.
Well done - Thanks a lot for the effort!!

[rprouse]

Great news @toralux, thanks for letting me know. For everyone else tracking this issue, the first release is out, you can find more info on my blog at http://www.alteridem.net/2017/05/04/test-net-core-nunit-vs2017/

I am going to leave this issue open so that people who are migrating can easily find it.

[kronwell]

Our thanks to @rprouse too! All of our 700+ unit tests written in NUnit against .Net Core assemblies are passing again. Great work indeed!!!

[EChaffraix]

Thanks @rprouse. Is there a parameter to generate Xml files ?

[rprouse]

@EChaffraix as far as I know we cannot generate NUnit XML results yet, so I added nunit/nunit3-vs-adapter#323 to track that.

If you are using dotnet test, you should be able to pass /logger:trx which will get passed on to vstest which should produce a Visual Studio Test Results File. I haven't had a chance to test yet.

[EChaffraix]

@rprouse Exactly ! Thank you.

Under linux le command is dotnet test --logger:trx. It works now perfectly on linux with Teamcity