Tag: nunitlite

In my previous post I showed how NUnitlite can provide a low-ceremony, minimal footprint option to run NUnit tests. The introduction of file-based apps in .NET 10 allow for this to be taken further. A file-based app no longer requires a project or solution file meaning everything can be run from a single .cs file as if it were a script. This can drastically simplify the setup process, reducing the chances of misconfiguration and allowing more time to be spent focusing on writing the tests themselves.

Referencing External Test Projects

The simplest scenario is to have the file-based app serve as a thin test host from which your tests can be run. This can be achieved in just a few lines:

#:package NUnitlite@4.5.1
#:project ../FileBasedApps.Tests/FileBasedApps.Tests.csproj
using NUnitLite;
using FileBasedApps.Tests;
// Use NUnitlite to execute the tests
new AutoRun(typeof(SampleTests).Assembly).Execute(args);

A file with those contents will:

1. Load version 4.5.1 of NUnitlite from NuGet
2. Load a project file from a relative path
3. Pass the test assembly into NUnitlite and run all discovered tests

It can be run from the command line with the following command:

dotnet run .\path-to\script-file.cs

Defining Inline Tests

More complex scenarios are also possible, such as having your script reference the system-under-test itself and then defining the tests directly within the C# script. This may be useful if you have a project or library and you’d like to quickly write a test to validate something without the ceremony of defining a full project and solution file. For this scenario, the example from my previous post can be used and modified slightly to load the desired system under test and to then define the test methods inline.

For example:

#:package NUnit@4.5.1
#:package NUnitlite@4.5.1
#:project ../FileBasedApps.Library/FileBasedApps.Library.csproj
using NUnitLite;
using NUnit.Framework;
using FileBasedApps.Library;
// Use NUnitlite to execute the tests
new AutoRun().Execute(args);
// The tests themselves
public class SampleTests
{
    [Test]
    public void Test1()
    {
        Assert.That(new SampleClass().MeaningOfLife, Is.EqualTo(42));
    }
}

The key difference here is that no assembly is passed into NUnitlite’s AutoRun constructor. This will cause NUnitlite to instead reference the calling assembly to find tests. This is desirable in this case as the assembly calling NUnitlite will resolve to the assembly generated for our top-level script file where our tests reside, allowing it to “just work” for NUnitlite to find the tests to run.

Passing Command-line Arguments

It’s possible to pass options to NUnitlite to customize behaviour in either scenario by passing them on the command line after a -- delimiter. For example, the below command will change the output location of the test results file:

dotnet run .\path-to\script-file.cs -- --result=CustomResultFile.xml

A full list of NUnitlite command line options can be found here.

Summary

In summary, NUnitlite and the new file-based apps feature in .NET 10 work well together and can provide a very quick and easy way to start writing tests. There are several options to structure your approach and all options can be further configured at runtime by passing command-line arguments.

Modern .NET development offers a wide range of testing frameworks and, separately, test runners. Test frameworks may range from NUnit to XUnit to MSTest or others, while runners may be first-party to each of those or third-party and framework-agnostic. These runners raise the level of abstraction and can offer helpful features, however sometimes it may be that you just want to run tests with as little ceremony as possible. This is where I’ve found NUnitlite to shine.

NUnitlite works with NUnit to allow your test assembly to become an executable, removing the need for an external runner altogether. This can be helpful in particular if there are limitations or disconnects to installing or updating runners in CI environments.

For example:

Suppose a CI test suite is initiated from a dedicated server but the tests must access private or secure resources like a database. You could allow access to the database from the CI server a security-conscious person might consider that to violate the Principle of Least Privilege. That could be fixed by simply configuring the CI server to run the tests from a dedicated machine, but that could also carry the undesirable consequence of installing dedicated test runners on that machine. Allowing tests to run themselves removes both the need to open access to a trusted resource as well as removes needing to install an additional piece of software.

This can be done in just a few steps:

• Install NUnitlite to your test project

<PackageReference Include="NUnitLite" Version="4.5.1" />

• OPTIONAL: Update your test project to output as an “Exe”

<OutputType>Exe</OutputType>

• Add a Program.cs file (if not using single-file applications) and include:

using NUnitLite;
return new AutoRun().Execute(args);

These three steps will turn the test assembly into an executable which can be easily and independently run. More information and examples can be found in the documentation.