Fluent Assertions in Unit Testing in C#

The xUnit Starting Point

[0:35 - 2:46] The project on screen is small: a class library with a single SampleClass that takes a full name in its constructor and splits it on the space into FirstName and LastName, plus an xUnit test project that exercises the happy path. The tests use Theory with InlineData attributes to run the same logic against two inputs ("Tim Corey" and "Sue Storm"), and each assertion is the standard Assert.Equal(expected, actual) form.

[Theory]
[InlineData("Tim Corey", "Tim")]
[InlineData("Sue Storm", "Sue")]
public void TestFirstNameProperty(string fullName, string expected)
{
    var sample = new SampleClass(fullName);
    Assert.Equal(expected, sample.FirstName);
}

[Theory]
[InlineData("Tim Corey", "Tim")]
[InlineData("Sue Storm", "Sue")]
public void TestFirstNameProperty(string fullName, string expected)
{
    var sample = new SampleClass(fullName);
    Assert.Equal(expected, sample.FirstName);
}

Running the suite gives six passing tests. Nothing about this is wrong, and for the cases that fit "first space last", the assertions read clearly enough. The interesting territory begins when a name does not fit that shape.

Where the Happy Path Stops Working

[2:46 - 4:32] The edge case Tim picks is "Eddie Van Halen", a three-word name where the surname is "Van Halen", not just the token after the first space. The current implementation grabs index 1 of the split and calls it the last name, so the class returns "Van" for the surname and drops "Halen" entirely. The bug is real, and writing a failing test for it is the first step toward fixing it.

Writing that test with Assert.Equal("Van Halen", sample.LastName) works, but the failure message reads as a string comparison without context. Switching to Fluent Assertions makes the same test express the rule in words and produce a failure message that names the property under test. For a small suite the difference looks cosmetic; for a suite of a few hundred assertions, the readability difference compounds.

Installing Fluent Assertions

[4:32 - 5:10] The package lives on NuGet under FluentAssertions. Tim flags it as one of the most-downloaded packages on the registry, which is useful context: any new contributor is statistically likely to have seen it before. The test project gets two using directives at the top:

using FluentAssertions;
using FluentAssertions.Execution;

using FluentAssertions;
using FluentAssertions.Execution;

The first one brings in the assertion extension methods, which is what most tests need. The second one exists for the AssertionScope type covered later in the video; tests that do not group assertions can leave it out.

The Should.Be Syntax

[5:10 - 6:14] The minimum Fluent Assertions rewrite of the Van Halen test:

[Fact]
public void TestEdgeCaseNames()
{
    var sample = new SampleClass("Eddie Van Halen");
    sample.LastName.Should().Be("Van Halen");
}

[Fact]
public void TestEdgeCaseNames()
{
    var sample = new SampleClass("Eddie Van Halen");
    sample.LastName.Should().Be("Van Halen");
}

The chain reads close to spoken English. The .Should() extension returns an assertion object whose methods describe the comparison; .Be(...) does an equality check. Case sensitivity, leading whitespace, and trailing whitespace are all part of that check, which matches the behavior of most string comparisons in production code.

Running this test against the broken implementation produces a failure message that names the property and explains the gap: "Expected sample.LastName to be 'Van Halen' with a length of 9, but 'Van' has a length of 3." The message identifies the value under test by the expression that produced it, which is the kind of context the bare Assert.Equal form does not provide.

Chaining Multiple Conditions

[6:14 - 8:10] A single property often needs to satisfy more than one rule. Fluent Assertions composes conditions with .And so the chain stays on one statement:

sample.LastName.Should()
    .StartWith("Van")
    .And.EndWith("len")
    .And.Contain(" ");

sample.LastName.Should()
    .StartWith("Van")
    .And.EndWith("len")
    .And.Contain(" ");

Each link in the chain is a separate condition. By default the chain stops reporting at the first failure: if StartWith("Van") passes but EndWith("len") fails, the failure message will name EndWith and the assertion stops there. For tests where each condition is independent and you want every failure surfaced, the assertion scope (next section) changes that behavior.

The chaining syntax leans toward expressing intent over enumerating equality. A test that says "the last name should start with Van, end with len, and contain a space" reads like a specification. The same logic written with three separate Assert.True calls would read as three boolean checks with no narrative connecting them.

Reporting Every Failure with Assertion Scopes

[8:10 - 9:34] The default behavior of stopping at the first failure is fine for chains where later conditions depend on earlier ones. For chains where every condition matters independently, wrapping the assertions in an AssertionScope makes the test report every failure in one run:

[Fact]
public void TestEdgeCaseNames()
{
    var sample = new SampleClass("Eddie Van Halen");

    using var _ = new AssertionScope();
    sample.LastName.Should().StartWith("Van");
    sample.LastName.Should().EndWith("len");
    sample.LastName.Should().Contain(" ");
}

[Fact]
public void TestEdgeCaseNames()
{
    var sample = new SampleClass("Eddie Van Halen");

    using var _ = new AssertionScope();
    sample.LastName.Should().StartWith("Van");
    sample.LastName.Should().EndWith("len");
    sample.LastName.Should().Contain(" ");
}

The using-var-discard line is the standard pattern: the scope lasts until the variable goes out of scope at the end of the method, and the discard underscore signals that the variable itself is never read. When the test fails, the message contains every failed condition as a separate line, which means one run gives the whole story instead of forcing three runs to surface three problems. For tests that verify the shape of a returned object across many properties, this is the difference between fixing one bug per test cycle and fixing all of them at once.

Wrapping Up: Tests That Read Like Specifications

[9:34 - 10:06] Fluent Assertions does not change what tests verify; it changes how the verification reads. The .Should() chain, the .And composition, and the AssertionScope grouping all push the test code closer to a written specification of the behavior under test. Combined with the same kind of fluent style used by FluentValidation for input validation, the pattern produces test suites and validation rules that newcomers can read without needing a tour.

Conclusion

[9:34 - 10:06] Adding Fluent Assertions to a test project takes one NuGet install, two using directives, and a rewrite of the assertion line from Assert.Equal(expected, actual) to actual.Should().Be(expected). Chains express multi-condition rules in a single statement, and AssertionScope makes a single test report every failure rather than stopping at the first. The payoff is failure messages that explain the rule that broke, which is the difference between a stack trace and a sentence.

Example Tip: When asserting on collections, prefer result.Should().BeEquivalentTo(expected) over property-by-property comparison. It walks the object graph for you and reports the first divergent property by path (for example, users[2].Address.City), which is far more useful than a "collections are not equal" message when a 50-element list disagrees on one nested field.

Watch full video on his YouTube Channel and gain more insights on writing readable, maintainable C# tests in the 10-Minute Training series.