WiX and InstallShield can both do it but both will take a huge learning curve either way. NSIS can do it also, if you consider running vbscripts during an installer elegant. Someone with experience could help you ramp up faster.
Update 4: The NUnit3TestAdapter v3.8 has been released, so it is no longer alpha.
Update 3:
With NUnit3TestAdapter v3.8.0-alpha1 it is possible now to run the tests using dotnet test
command. You just need to have these dependencies in your test project:
<PackageReference Include="nunit" Version="3.7.0" />
<PackageReference Include="NUnit3TestAdapter" Version="3.8.0-*" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.*" />
You can try it out!
Update 2: Visual Studio 2017 and the move from project.json
to csproj
made the dotnet-test-nunit
test adapter obsolete, so we needed to release another updated adapter to run .NET Core tests. Please see Testing .NET Core with NUnit in Visual Studio 2017 if you are using VS2017 and the new .NET Core tooling. See the update below if you are using project.json
.
Update: NUnit now has support for dotnet test
, so you no longer have to use NUnitLite. See testing .NET Core RC2 and ASP.NET Core RC2 using NUnit 3.
NUnit console (and the underlying NUnit Engine) do not support running unit tests against .NET core yet. Hopefully we will get that support in NUnit 3.4.
In the meantime, you can use NUnitLite to switch your tests to a self-executing test runner.
I wrote a blog post on the process at Testing .NET Core using NUnit 3. A quick summary is;
- Create a .NET Core Console application for your test project.
- Reference NUnit and NUnitLite from your test project. You do not need the runner.
- Modify
main()
to execute the unit tests.
It should look like this;
using NUnitLite;
using System;
using System.Reflection;
namespace MyDnxProject.Test
{
public class Program
{
public int Main(string[] args)
{
var writter = new ExtendedTextWrapper(Console.Out);
new AutoRun(typeof(Program).GetTypeInfo().Assembly).Execute(args, writter, Console.In);
}
}
}
For more complete information, see my blog post.
Best Answer
At the time of writing this answer, the latest NUnit version is v3.5 and xUnit.net is v2.1.
Both frameworks are awesome, and they both support parallel test running (in a different way though). NUnit has been around since 2002, it's widely used, well documented and has a large community, whereas xUnit.net is more modern, more TDD adherent, more extensible, and also trending in .NET Core development. It's also well documented.
In addition to that, the main difference I noticed is the way that xUnit.net runs the test methods. So, in NUnit, we've got a test class and a set of test methods in it. NUnit creates a new instance of the test class and then runs all of the test methods from the same instance. Whereas xUnit.net creates a new instance of the test class for very each of the test methods. Therefore, one cannot use fields or properties to share data among test methods which is a bad practice, as our test methods would be dependent to each other which is not acceptable in TDD. So if you use xunit.net, you could be sure that your test methods are completely isolated.
If you're willing to share some data among your test methods though, xUnit will let you do so. Therefore, by default all test methods are completely isolated, but you can break this isolation in specific cases intentionally. I fancy this attitude, that's why I like it better.