Unit testing with xUnit

Why automated tests?

Every change risks breaking something that used to work. Clicking through the app after each change is slow and you'll skip it eventually. Automated tests check behavior in seconds, every time — on your machine and in CI on every push. They also document how code is supposed to behave, and they make refactoring safe.

A unit test checks a small piece of logic in isolation: one method or class, with no real database, network or file system. Unit tests run in milliseconds, so you can have thousands.

Setting up xUnit

xUnit is the most popular .NET test framework (NUnit and MSTest are alternatives with similar ideas):

dotnet new xunit -o Shop.Tests
dotnet add Shop.Tests reference Shop.Core      # the project being tested
dotnet test                                    # build and run all tests

Your first tests

public class PasswordValidatorTests
{
    [Fact]
    public void Validate_ValidPassword_ReturnsNoErrors()
    {
        // Arrange
        var password = "Password1";
 
        // Act
        var errors = PasswordValidator.Validate(password);
 
        // Assert
        Assert.Empty(errors);
    }
 
    [Fact]
    public void Validate_ShortPassword_ReportsTooShort()
    {
        var errors = PasswordValidator.Validate("Ab1");
 
        Assert.Contains("Too short", errors);
    }
 
    [Theory]
    [InlineData("password1", "Needs an uppercase letter")]
    [InlineData("Passwords", "Needs a digit")]
    public void Validate_MissingRule_ReportsIt(string password, string expectedError)
    {
        var errors = PasswordValidator.Validate(password);
 
        Assert.Equal([expectedError], errors);
    }
}

[Fact] — a single test case.
[Theory] + [InlineData] — the same test with several inputs.
Arrange, Act, Assert — set up, do one thing, check the outcome.
Names describe what, when and expected result: Method_Scenario_ExpectedBehavior.

These are exactly the checks this lesson's exercise runs. Make them pass!

Assertions

Assertion	Checks
`Assert.Equal(expected, actual)`	Values are equal (works with collections too)
`Assert.True(cond)` / `Assert.False(cond)`	A condition
`Assert.Null(x)` / `Assert.NotNull(x)`	Nullness
`Assert.Contains(item, collection)` / `Assert.Empty(c)`	Collections
`Assert.Throws<ArgumentException>(() => ...)`	An exception is thrown
`await Assert.ThrowsAsync<T>(async () => ...)`	Same, for async code

Put expected first, actual second — failure messages read "Expected: X, Actual: Y". Libraries like FluentAssertions or Shouldly offer a more readable style: errors.Should().BeEmpty();.

What makes a good unit test

Fast — milliseconds. No sleeps, no real I/O.
Isolated — tests don't depend on each other or on execution order.
Repeatable — same result every run. Inject the clock (TimeProvider) and seed randomness; flaky tests are worse than none.
One reason to fail — test one behavior; many small tests beat one giant test.
Test behavior, not implementation — assert on results, not on private details, so refactoring doesn't break tests.

What to test

Focus on code with logic: calculations, validation, business rules, edge cases (empty lists, nulls, boundaries like exactly 8 characters). Don't bother unit-testing trivial getters or framework code — and test infrastructure (databases, HTTP) with integration tests instead (later in this track).

Tests in this course

Every exercise you've solved was checked by hidden tests — the same idea as xUnit, running in your browser. Writing the tests yourself is the next step.

Key takeaways

Unit tests check small pieces of logic in isolation, quickly and automatically.
xUnit: [Fact] for one case, [Theory] + [InlineData] for many; run with dotnet test.
Structure tests as Arrange-Act-Assert with descriptive names.
Keep tests fast, isolated and deterministic; test behavior, not implementation details.

You will learn