Test Doubles

A test double is any stand-in you put in place of a real dependency while testing.

The name comes from the film industry: a stunt double stands in for the actor when the real thing is impractical. The same logic applies here. OrderService needs an IOrderRepository, and the real one talks to a database. For a test about discount arithmetic, a database is slow, needs setup, and can fail for reasons that have nothing to do with the arithmetic.

The word "mock" is often used for all of these, which is why people end up with tests that do the wrong thing. The four kinds behave differently, and the difference determines whether your test survives a refactor.

There is a fifth name you will meet occasionally: a dummy. It is an object passed in only to satisfy a constructor, never called. If a test needs a logger it does not care about, the logger is a dummy.

public interface IOrderRepository
{
    Order? Find(Guid id);
    IReadOnlyList<Order> FindByEmployee(string employeeId);
    void Save(Order order);
}

• An interface is what makes substitution possible. OrderService is given an IOrderRepository and has no idea which implementation it received.
• In production it gets the one that talks to the database. In tests it gets whichever double suits the test.
• This is dependency injection doing the work. The testability is not a happy accident — it is the main practical reason to inject dependencies rather than construct them inside the class.

public class StubOrderRepository : IOrderRepository
{
    private readonly Order? _order;

    public StubOrderRepository(Order? order) => _order = order;

    public Order? Find(Guid id) => _order;

    public IReadOnlyList<Order> FindByEmployee(string employeeId) => Array.Empty<Order>();

    public void Save(Order order) { }
}

• Find returns the same order regardless of the id. That is deliberate — the test is not about lookup, so the stub does not pretend to look anything up.
• Save does nothing. A stub is allowed to ignore calls it is not there to support.
• Useful when the test needs the dependency to answer a question so the real logic can run. Not useful when the test needs to check what was stored.

public class InMemoryOrderRepository : IOrderRepository
{
    private readonly Dictionary<Guid, Order> _orders = new();

    public Order? Find(Guid id) =>
        _orders.TryGetValue(id, out Order? order) ? order : null;

    public IReadOnlyList<Order> FindByEmployee(string employeeId) =>
        _orders.Values.Where(o => o.EmployeeId == employeeId).ToList();

    public void Save(Order order) => _orders[order.Id] = order;
}

• This one works. Save something, find it again, and you get it back — the same contract the database-backed implementation honours.
• Tests can therefore assert on outcomes: after calling Submit, the stored order has the submitted status. That assertion holds whatever the service does internally.
• One fake serves a whole test class, and often a whole test project. The cost is writing it once and keeping it honest as the interface grows.

public class SpyOrderRepository : IOrderRepository
{
    public List<Order> SavedOrders { get; } = new();

    public Order? Find(Guid id) => SavedOrders.FirstOrDefault(o => o.Id == id);

    public IReadOnlyList<Order> FindByEmployee(string employeeId) => SavedOrders;

    public void Save(Order order) => SavedOrders.Add(order);
}

• The recording is the point: SavedOrders is a public list the test can examine after the act.
• A spy does not fail on its own. The test decides what matters — usually the content of what was saved rather than how many times Save ran.
• In practice a good fake often doubles as a spy, because being able to read the stored state is exactly what you need.