Unit Testing Mastery (xUnit, NUnit, MSTest)

By the end of this lesson you'll be able to write unit tests that pin down a method's behaviour, structure every test with Arrange-Act-Assert, name tests so failures read like sentences, and drive many cases from one method with [Theory] and [InlineData] — the safety net that lets you change code without fear.

1. Why Test, and the Arrange-Act-Assert Shape

A unit test is automated code that runs one small piece of your program — a single method, the "unit" — with a known input and checks it produces the expected output. You write them so a computer re-verifies your logic in seconds every time you change something, instead of you clicking through the app by hand. Every good test follows the same three-part shape: Arrange the inputs, Act by calling the one method under test, then Assert the result is what you expect. Name the test Method_Scenario_Expected so a red result tells the whole story without opening the file. Read this worked example — it hand-rolls a tiny AssertEqual so you see exactly what an assertion does — then run it.

using System;

class Program
{
    // The "unit" under test — a tiny pure function we want to verify.
    static int Add(int a, int b) => a + b;

    // A minimal assertion helper. A real framework (xUnit) gives you this,
    // but writing it once shows you exactly what an assert DOES:
    // compare expected vs actual, then report PASS or FAIL.
    static void AssertEqual(int expected, int actual, string testName)
    {
        if (expected == actual)
            Console.WriteLine($"PASS: {tes
...

Your turn. The program below is almost complete — finish the Act and Assert lines so the test of Add passes. Fill in the two ___ blanks using the hints, then run it.

using System;

class Program
{
    static int Add(int a, int b) => a + b;

    // 🎯 YOUR TURN — finish the helper, then finish the test.

    static void AssertEqual(int expected, int actual, string testName)
    {
        // 1) Compare expected and actual. Print PASS if equal, FAIL if not.
        if (expected == actual)
            Console.WriteLine($"PASS: {testName}");
        else
            Console.WriteLine($"FAIL: {testName} — expected {expected}, got {actual}");
    }

    static void
...

2. Testing Edge Cases

The "happy path" (normal inputs) is the easy half. Bugs hide in the edge cases — zero, empty, negative, the maximum, the boundary where behaviour changes. A good test suite has one test per interesting edge, each with its own clear name, so when an edge breaks you see precisely which one. Here the discount function must never return a negative price; your job is to test the edge where the discount is bigger than the price itself.

using System;

class Program
{
    // The unit under test: should never return a negative price.
    static decimal ApplyDiscount(decimal price, decimal percentOff)
    {
        decimal result = price - (price * percentOff / 100);
        return result < 0 ? 0 : result;   // clamp at zero — the EDGE we test
    }

    static void AssertEqual(decimal expected, decimal actual, string testName)
    {
        if (expected == actual)
            Console.WriteLine($"PASS: {testName}");
        else
 
...

3. Real xUnit: [Fact], [Theory] & Assertions

In a real project you don't hand-roll AssertEqual — a framework gives you it and a test runner. In xUnit, [Fact] marks a method as a single test with no inputs. [Theory] with one or more [InlineData(...)] rows runs the same test body once per row, so five cases live in one method instead of five copy-pasted ones. You run them all with dotnet test. The example below is exactly what you'd commit — read how each test maps onto the Arrange-Act-Assert shape you just practised.

using Xunit;

// The class we are testing — plain business logic, no test code inside it.
public class Calculator
{
    public int Add(int a, int b) => a + b;
    public bool IsEven(int n) => n % 2 == 0;
    public int Divide(int a, int b)
    {
        if (b == 0) throw new DivideByZeroException("Cannot divide by zero");
        return a / b;
    }
}

// A test CLASS groups related tests. xUnit makes a fresh instance per test,
// so tests never share state — that isolation is built in.
public c
...

4. Choosing the Right Assertion

An assertion is the line that decides pass or fail. Always reach for the most specific one: Assert.Equal(8, result) tells you "Expected 8, Actual 7" when it fails, whereas Assert.True(result == 8) only tells you "false" — useless for debugging. xUnit has a rich set: Equal/NotEqual, True/False, Null/NotNull, Contains, StartsWith, Throws<T>, and All for collections. Note floating-point: never assert exact equality on a double — pass a precision instead.

using Xunit;
using System.Collections.Generic;

public class AssertionShowcase
{
    [Fact]
    public void Equality_PrefersAssertEqual()
    {
        // Use the MOST specific assert you can. Assert.Equal gives a clear
        // "Expected: 8, Actual: 7" message; Assert.True(x == y) only says "false".
        Assert.Equal(8, 5 + 3);              // numbers
        Assert.Equal("HELLO", "hello".ToUpper());  // strings
        Assert.NotEqual(0, 5);
    }

    [Fact]
    public void Booleans_And_
...

public class CartTests
{
    // Runs BEFORE EACH test — every test gets a fresh, empty cart.
    private readonly Cart _cart = new();

    [Fact] public void Add_OneItem_CountIsOne()  { _cart.Add("x"); Assert.Equal(1, _cart.Count); }
    [Fact] public void NewCart_IsEmpty()         { Assert.Equal(0, _cart.Count); }  // unaffected by the test above
}

using System;

class Program
{
    // The unit under test — a simple FizzBuzz-style classifier.
    static string Classify(int n)
    {
        if (n % 15 == 0) return "FizzBuzz";
        if (n % 3 == 0)  return "Fizz";
        if (n % 5 == 0)  return "Buzz";
        return n.ToString();
    }

    static void Main()
    {
        // 🎯 MINI-CHALLENGE: test Classify across several cases, count pass/fail.
        // 1. Keep two counters: int passed = 0, failed = 0.
        // 2. Write a small Che
...