v3 test projects are programs instead of libraries

[bradwilson]

A major architectural change in v3 is that test projects are now programs rather than libraries.

This change was made to better support platforms like .NET Core, which did not exist in 2006 when we first started working on xUnit.net v1. The decision back then to make unit tests be DLLs that were loaded in-memory by the console runner was reasonable at the time, but has not served us well as additional target platforms were added.

In practice, what this means is that any single unit test assembly is completely self-hosted: after you build it, you can run it without requiring any additional tooling. Examples of this will be shown below.

We will continue to ship stand-alone runners (like the console and MSBuild runners), which will continue to allow you to run multiple test assemblies simultaneously, as well as third party integration runners (like the TestDriven.NET and Visual Studio runners).

.NET Core

Test projects compile to console programs (resulting in a .dll file). To invoke the tests, you can use dotnet run:

There is a command line front end which you can invoke by adding the command line switch -? (after --, which tells dotnet run that you're passing command line options to your program rather than to dotnet run), which provides a list of options very similar to the stand-alone console test runner:

.NET Framework

Test projects compile to console programs (resulting in an .exe file). To invoke the tests, simply run the executable (with Mono, if you're on Linux or macOS):

There is a command line front end which you can invoke by adding the command line switch -?, which provides a list of options very similar to the stand-alone console test runner: