Test Data

Most unit tests need an object before they can do anything. An order, a customer, an employee. Building that object is the part of a test that quietly gets out of hand.

The problem is not length for its own sake. It is that a reader cannot see which value the test depends on. If an order is constructed with nine arguments and the assertion is about one of them, the other eight are noise that the reader still has to scan.

A test data builder fixes that by giving every field a valid default and letting each test state only its difference. The scenario then reads off the arrange block without any decoding.

[Fact]
public void ApplyLoyaltyDiscount_ForOrderOverOneHundred_ReducesTotalByFivePercent()
{
    var order = new Order(
        Guid.NewGuid(),
        "E-1042",
        new DateOnly(2026, 3, 14),
        OrderStatus.Draft,
        quantity: 8,
        unitPrice: 25m,
        shippingFee: 4.95m,
        notes: null);

    _service.ApplyLoyaltyDiscount(order);

    Assert.Equal(190m, order.Total);
}

[Fact]
public void Submit_WhenOrderIsCancelled_Throws()
{
    var order = new Order(
        Guid.NewGuid(),
        "E-1042",
        new DateOnly(2026, 3, 14),
        OrderStatus.Cancelled,
        quantity: 8,
        unitPrice: 25m,
        shippingFee: 4.95m,
        notes: null);

    Assert.Throws<InvalidOperationException>(() => _service.Submit(order));
}

• The two tests differ in exactly one field: the status. Nothing about the code makes that visible, so a reader compares two blocks line by line to find it.
• The date, the shipping fee and the notes have no bearing on either test. They are there because the constructor demands them, and every one of them is a value a reader has to decide to ignore.
• The second test also depends on a value that is easy to get wrong silently. If somebody reorders the constructor parameters so that quantity and unitPrice swap, both tests still compile and the first one starts asserting on a different number.
• Duplication is the smaller cost here. Add a tenth constructor parameter and every test in the class needs editing, which is the kind of change people make without reading what they are editing.

public class OrderBuilder
{
    private string _employeeId = "E-1042";
    private OrderStatus _status = OrderStatus.Draft;
    private int _quantity = 8;
    private decimal _unitPrice = 25m;

    public OrderBuilder WithStatus(OrderStatus status)
    {
        _status = status;
        return this;
    }

    public OrderBuilder WithLine(int quantity, decimal unitPrice)
    {
        _quantity = quantity;
        _unitPrice = unitPrice;
        return this;
    }

    public Order Build() => new Order(
        Guid.NewGuid(),
        _employeeId,
        new DateOnly(2026, 3, 14),
        _status,
        _quantity,
        _unitPrice,
        shippingFee: 4.95m,
        notes: null);
}

// -- in the test class --

[Fact]
public void ApplyLoyaltyDiscount_ForOrderOverOneHundred_ReducesTotalByFivePercent()
{
    Order order = new OrderBuilder().WithLine(quantity: 8, unitPrice: 25m).Build();

    _service.ApplyLoyaltyDiscount(order);

    Assert.Equal(190m, order.Total);
}

[Fact]
public void Submit_WhenOrderIsCancelled_Throws()
{
    Order order = new OrderBuilder().WithStatus(OrderStatus.Cancelled).Build();

    Assert.Throws<InvalidOperationException>(() => _service.Submit(order));
}

• Every field starts at a value that produces a valid order. A test that says nothing about shipping or dates gets a working order anyway.
• Each With method returns this, so calls can be chained. That is the only reason for the return type — there is no cleverness hiding in it.
• The second test now says what it is about in one line: an order whose status is cancelled. The first test keeps its line values because the assertion depends on them, and that is exactly the distinction you want visible.
• Build() returns a new instance every time it is called, so two tests can never share an object. A builder that caches and returns the same order would reintroduce the coupling this is meant to remove.
• Only add a With method when a test needs to vary that field. A builder with a method for all nine fields on the first day is speculative work, and half of it will never be called.