Test doubles: fakes, stubs and mocks

Why replace dependencies in tests?

Imagine testing an OrderService that charges a card and sends an SMS. Running it for real in every test would charge real money, send real messages, need the internet and take seconds. A unit test should check only OrderService's own logic. So you hand it pretend versions of the payment gateway and SMS sender.

The kinds of test doubles

Code designed for testing

public interface IPaymentGateway { Task<bool> ChargeAsync(string cardToken, decimal amount); }
public interface ISmsSender { Task SendAsync(string phone, string text); }

public class OrderService(IPaymentGateway payments, ISmsSender sms)
{
    public async Task<string> PlaceAsync(string phone, string cardToken, decimal amount)
    {
        if (amount <= 0) return "Invalid amount";
        bool paid = await payments.ChargeAsync(cardToken, amount);
        if (!paid) return "Payment failed";
        await sms.SendAsync(phone, $"Order confirmed: Rs {amount}");
        return "Confirmed";
    }
}

Hand-written doubles

class StubGateway(bool result) : IPaymentGateway
{
    public Task<bool> ChargeAsync(string cardToken, decimal amount) => Task.FromResult(result);
}

class SpySms : ISmsSender
{
    public List<(string Phone, string Text)> Sent { get; } = new();
    public Task SendAsync(string phone, string text)
    {
        Sent.Add((phone, text));
        return Task.CompletedTask;
    }
}

public class OrderServiceTests
{
    [Fact]
    public async Task Place_PaymentSucceeds_SendsOneSms()
    {
        var sms = new SpySms();
        var service = new OrderService(new StubGateway(true), sms);

        string result = await service.PlaceAsync("98xxxxxx10", "tok_123", 499m);

        Assert.Equal("Confirmed", result);
        Assert.Single(sms.Sent);
        Assert.Contains("499", sms.Sent[0].Text);
    }

    [Fact]
    public async Task Place_PaymentFails_SendsNoSms()
    {
        var sms = new SpySms();
        var service = new OrderService(new StubGateway(false), sms);

        string result = await service.PlaceAsync("98xxxxxx10", "tok_123", 499m);

        Assert.Equal("Payment failed", result);
        Assert.Empty(sms.Sent);
    }
}

Controlling time

Code that uses DateTime.Now directly is hard to test ("is the shop open?" depends on when the test runs). Since .NET 8, the framework has an abstract TimeProvider class. Inject it, use TimeProvider.System in the real app, and pass a fake one in tests (Microsoft publishes a FakeTimeProvider in the Microsoft.Extensions.TimeProvider.Testing package), or write your own small IClock interface.

Mocking libraries

Writing doubles by hand is clear and fine for small interfaces. For bigger ones, teams use mocking libraries that create doubles at run time. Moq and NSubstitute are the most widely used in .NET; you will see them in many job descriptions. Their syntax differs, so learn whichever your project uses from its official documentation. The idea is always the same: set up what a method should return, and verify which calls were made.

Unit tests versus integration tests

Unit tests check one class with its dependencies replaced. Integration tests check several real parts together, for example the whole Web API with a real (test) database. ASP.NET Core supports this with WebApplicationFactory from the Microsoft.AspNetCore.Mvc.Testing package, which starts your app in memory so tests can send real HTTP requests to it. A healthy project has many fast unit tests and fewer, slower integration tests.

Common mistakes and fixes

• Classes that create their own dependencies with new: they cannot be tested in isolation. Inject interfaces.
• Mocking everything, including simple value objects and the class under test: tests become a copy of the implementation and break on every refactor. Double only the slow or risky edges.
• Verifying every single call: test the outcome that matters (an SMS was sent with the amount), not every internal step.
• Using static helpers for I/O (File, DateTime.Now) deep inside business logic: wrap them behind an interface at the edge.