NUnit and FluentAssertions: Write Expressive .NET Tests

In the world of .NET development, writing tests is not just a good practice; it's a necessity for building reliable, maintainable software. However, the way you write those tests can significantly impact your team's productivity and the long-term health of your codebase. Traditional assertion libraries often lead to cryptic test failures that require digging into logs or debugging sessions. This is where NUnit and FluentAssertions come to the rescue.

NUnit is a mature, feature-rich unit testing framework that has been a cornerstone of .NET testing for years. It provides a robust infrastructure for organizing and running tests, with attributes like [TestFixture] and [Test] that make test structure clear. On the other hand, FluentAssertions is a library that revolutionizes how you write assertions. Instead of writing Assert.AreEqual(expected, actual), you write actual.Should().Be(expected). This simple change makes tests read like natural language, improving readability and reducing cognitive load.

Imagine you're working on a payment processing system. A test failure like 'Expected 100 but got 99' is vague. With FluentAssertions, you get 'Expected actual to be 100, but found 99'. That extra context can save hours of debugging. In this tutorial, you'll learn how to set up NUnit and FluentAssertions, write expressive tests, and avoid common pitfalls. By the end, you'll be able to write tests that not only catch bugs but also serve as living documentation for your code.

Setting Up NUnit and FluentAssertions

To get started, create a new .NET project and add the necessary NuGet packages. You can use the .NET CLI or Visual Studio. First, create a class library project for your production code and a test project. For the test project, install NUnit and FluentAssertions.

``bash dotnet new nunit -n MyTests cd MyTests dotnet add package FluentAssertions ``

This creates a test project with NUnit already included. FluentAssertions is added separately. Once installed, you can write your first test. In NUnit, tests are methods marked with the [Test] attribute inside a class marked with [TestFixture]. Here's a simple example:

using NUnit.Framework;
using FluentAssertions;

[TestFixture]
public class CalculatorTests
{
    [Test]
    public void Add_ShouldReturnSum()
    {
        // Arrange
        var calculator = new Calculator();
        int a = 2, b = 3;

        // Act
        var result = calculator.Add(a, b);

        // Assert
        result.Should().Be(5);
    }
}

Writing Your First Test with FluentAssertions

FluentAssertions provides a rich set of extension methods that make assertions read like natural language. Instead of Assert.AreEqual(expected, actual), you write actual.Should().Be(expected). This not only improves readability but also provides better error messages. For example, if the assertion fails, FluentAssertions will tell you what the expected and actual values were, and even show the difference.

Let's test a simple string manipulation method. Consider a method that reverses a string:

[TestFixture]
public class StringHelperTests
{
    [Test]
    public void Reverse_ShouldReturnReversedString()
    {
        // Arrange
        var helper = new StringHelper();
        string input = "hello";

        // Act
        var result = helper.Reverse(input);

        // Assert
        result.Should().Be("olleh");
    }

    [Test]
    public void Reverse_WhenEmptyString_ShouldReturnEmpty()
    {
        // Arrange
        var helper = new StringHelper();
        string input = "";

        // Act
        var result = helper.Reverse(input);

        // Assert
        result.Should().BeEmpty();
    }
}

Testing Collections and Dictionaries

Collections are common in business logic. FluentAssertions offers powerful methods to verify collection contents, order, and counts. For example, you can check that a list contains specific items, or that it is sorted.

Consider a method that returns a list of prime numbers up to a given limit:

[TestFixture]
public class PrimeGeneratorTests
{
    [Test]
    public void GetPrimesUpTo_ShouldReturnPrimes()
    {
        // Arrange
        var generator = new PrimeGenerator();

        // Act
        var primes = generator.GetPrimesUpTo(10);

        // Assert
        primes.Should().HaveCount(4)
              .And.ContainInOrder(2, 3, 5, 7)
              .And.NotContain(4);
    }

    [Test]
    public void GetPrimesUpTo_WhenLimitIs1_ShouldReturnEmpty()
    {
        // Arrange
        var generator = new PrimeGenerator();

        // Act
        var primes = generator.GetPrimesUpTo(1);

        // Assert
        primes.Should().BeEmpty();
    }
}

Exception Testing with FluentAssertions

Testing that code throws expected exceptions is crucial for error handling. FluentAssertions provides a clean syntax for this. Instead of using NUnit's Assert.Throws, you can write a lambda and assert on the exception.

Consider a method that divides two numbers and throws DivideByZeroException when denominator is zero:

[TestFixture]
public class CalculatorExceptionTests
{
    [Test]
    public void Divide_WhenDenominatorIsZero_ShouldThrowDivideByZeroException()
    {
        // Arrange
        var calculator = new Calculator();

        // Act
        Action act = () => calculator.Divide(10, 0);

        // Assert
        act.Should().Throw<DivideByZeroException>()
           .WithMessage("Attempted to divide by zero.");
    }

    [Test]
    public void Divide_WhenDenominatorIsZero_ShouldThrowExceptionWithSpecificMessage()
    {
        // Arrange
        var calculator = new Calculator();

        // Act
        Func<object> act = () => calculator.Divide(10, 0);

        // Assert
        act.Should().Throw<DivideByZeroException>()
           .And.Message.Should().Contain("divide by zero");
    }
}

Using TestCase and TestCaseSource for Data-Driven Tests

NUnit supports parameterized tests with [TestCase] and [TestCaseSource] attributes. This allows you to run the same test logic with multiple inputs, reducing code duplication. Combine this with FluentAssertions for expressive data-driven tests.

Consider a method that checks if a number is even:

[TestFixture]
public class NumberTests
{
    [TestCase(2)]
    [TestCase(4)]
    [TestCase(100)]
    public void IsEven_ShouldReturnTrue_ForEvenNumbers(int number)
    {
        // Arrange
        var checker = new NumberChecker();

        // Act
        var result = checker.IsEven(number);

        // Assert
        result.Should().BeTrue();
    }

    [TestCaseSource(nameof(OddNumbers))]
    public void IsEven_ShouldReturnFalse_ForOddNumbers(int number)
    {
        // Arrange
        var checker = new NumberChecker();

        // Act
        var result = checker.IsEven(number);

        // Assert
        result.Should().BeFalse();
    }

    private static IEnumerable<int> OddNumbers()
    {
        yield return 1;
        yield return 3;
        yield return 99;
    }
}

Best Practices and Common Pitfalls

Writing good tests is as important as writing good production code. Here are some best practices when using NUnit and FluentAssertions:

1. Keep tests independent: Each test should set up its own data and not rely on other tests. Use [SetUp] and [TearDown] for common initialization.
2. Use meaningful assertions: Prefer FluentAssertions over NUnit's classic assertions for better readability.
3. Avoid logic in tests: Tests should be simple and not contain complex logic. If you need loops or conditionals, consider refactoring.
4. Test one thing per test: Each test should verify a single behavior. Use multiple assertions only if they are related.
5. Name tests clearly: Follow a naming convention like MethodName_ShouldExpectedBehavior_WhenCondition.

[TestFixture]
public class BestPracticesDemo
{
    private Calculator _calculator;

    [SetUp]
    public void Setup()
    {
        _calculator = new Calculator();
    }

    [Test]
    public void Add_ShouldReturnSum_WhenBothNumbersPositive()
    {
        // Arrange
        int a = 5, b = 10;

        // Act
        var result = _calculator.Add(a, b);

        // Assert
        result.Should().Be(15);
    }

    [TearDown]
    public void Cleanup()
    {
        // Dispose resources if needed
    }
}