Mocking & Test Doubles

By the end of this lesson you'll be able to isolate the class you're testing from its dependencies — databases, email, web APIs — by replacing them with test doubles. You'll hand-roll your own fakes, then use Moq to do it in two lines, and you'll know the difference between testing state and testing interactions — plus when not to mock at all.

1. Hand-Rolling a Fake That Records Calls

Before any framework, understand what a double actually is — just a class that implements the same interface as the real thing. The key trick that makes it swappable is dependency injection: the class under test takes its dependency through its constructor rather than creating it, so in a test you hand it a double instead. This first double is a spy — it records how many times Send was called so the test can check the interaction. Read it, run it, then you'll build one.

using System;
using System.Collections.Generic;

// The dependency we want to keep OUT of our test — in real life this would
// actually send email over the network. We never want a unit test to do that.
interface IEmailService
{
    void Send(string to, string subject);
}

// A hand-rolled FAKE (a "spy"): it implements the interface but instead of
// sending anything, it just RECORDS what it was asked to do. No framework needed.
class FakeEmailService : IEmailService
{
    public int SendCount 
...

Your turn. The fake below is missing the bits that make it record anything. Fill in the three ___ blanks so the test can count the emails, then run it.

using System;

// 🎯 YOUR TURN — finish the FAKE so the test can count Send calls.
interface IEmailService
{
    void Send(string to, string subject);
}

class FakeEmailService : IEmailService
{
    // 1) Add a counter the test can read later, starting at 0.
    public int SendCount = ___;        // 👉 start the count at  0

    public void Send(string to, string subject)
    {
        // 2) Record this call by increasing the counter by one.
        ___;                           // 👉 increment
...

2. Stubs — Canned Data for Deterministic Tests

A stub solves a different problem from a spy. Where a spy watches calls going out, a stub feeds data in: it returns the same fixed value every time, so the method under test produces the same result on every run. That's what makes a test deterministic — it never depends on what's in a real database or what a remote API happens to return today. Here the stub always reports a price of £10, so you can assert the discount maths exactly. Fill in the two blanks.

using System;

// A STUB feeds CANNED data to the code under test so it behaves the same way
// every run — no real database, no randomness. We test the LOGIC, deterministically.

interface IPriceProvider
{
    decimal GetPrice(string sku);     // real version would hit a database
}

// 🎯 YOUR TURN — finish the stub so GetPrice always returns a fixed value.
class StubPriceProvider : IPriceProvider
{
    public decimal GetPrice(string sku)
    {
        // 1) Ignore the sku and always return the
...

3. Moq — Setup, Returns & Verify

Hand-rolling a double for every interface gets tedious. Moq is the most popular .NET mocking library: new Mock<IFoo>() generates a fake implementation at runtime, and you reach the fake object via .Object. You stub a return value with .Setup(x => x.Method(arg)).Returns(value), and you assert an interaction happened with .Verify(x => x.Method(arg), Times.Once). The next two examples are real test code — read them and note the expected outcome in each comment (the runnable exercises above already let you practise the underlying idea by hand).

using Moq;
using Xunit;

public interface IUserRepository
{
    User? GetById(int id);
    void Add(User user);
}

public interface IEmailService
{
    void SendWelcome(string email);
}

public class User { public int Id; public string Name = ""; public string Email = ""; }

// Service under test — depends only on interfaces (so they can be mocked).
public class UserService
{
    private readonly IUserRepository _repo;
    private readonly IEmailService _email;
    public UserService(IUserReposi
...

4. Verifying Calls: Times, Matchers & NSubstitute

Verify takes a Times argument — Times.Once, Times.Never, Times.Exactly(n) — to assert how many times a call happened. When you don't care about the exact argument, match any value with It.IsAny<T>() or a predicate with It.Is<T>(...). NSubstitute is a popular alternative with lighter syntax — no .Object, no Setup keyword; you stub with .Returns(...) and verify with .Received(n). Pick one per project and stay consistent.

using Moq;
using Xunit;

public class VerifyAndMatchersTests
{
    [Fact]
    public void Verify_CountsAndArgumentMatchers()
    {
        var email = new Mock<IEmailService>();

        // Drive the mock a couple of times.
        email.Object.SendWelcome("a@test.com");
        email.Object.SendWelcome("b@test.com");

        // Times.Exactly(n) — assert the EXACT number of calls.
        // It.IsAny<string>() — match ANY string argument.
        email.Verify(e => e.SendWelcome(It.IsAny<string>
...

// STATE: stub the input, assert the output.
repo.Setup(r => r.GetById(1)).Returns(new User { Name = "Al" });
Assert.Equal("Al", service.GetName(1));

// INTERACTION: drive the code, assert the call happened.
service.Register("Bob", "bob@x.com");
email.Verify(e => e.SendWelcome("bob@x.com"), Times.Once);

using System;
using System.Collections.Generic;

// 🎯 MINI-CHALLENGE: test a service using a hand-rolled fake repository.
//
// 1. Implement IRepository with an in-memory fake:
//    - back it with a  List<string>  field called Saved
//    - Save(item) should add the item to that list
//    - Count() should return how many items have been saved
// 2. In Main, inject your fake into the NoteService below.
// 3. Call service.AddNote("buy milk") and service.AddNote("call mum").
// 4. Assert the fak
...