Unit testing with fakes

A unit test exercises one class with its dependencies replaced by test doubles. The words are used loosely, but they mean different things:

• a dummy is passed only to satisfy a signature;
• a stub returns canned answers;
• a fake is a working, simplified implementation, such as an in-memory repository;
• a spy records how it was called, for the test to inspect;
• a mock is set up with expectations and verifies them, usually through a library such as Moq or NSubstitute.

Constructor injection is what makes this possible: a class that asks for IEmailSender can be given a spy, while one that calls new SmtpClient() cannot.

public class TrialTests
{
    [Theory]
    [InlineData(13, true)]
    [InlineData(14, false)]
    public void Trial_lasts_fourteen_days(int days, bool expected) { /* ... */ }
}

Time is a dependency

Code that reads DateTime.UtcNow directly cannot be tested at day 13 and day 14 without waiting. Since .NET 8 the base class library has an abstraction for this: inject TimeProvider (register TimeProvider.System in production) and override GetUtcNow() in tests. The Microsoft.Extensions.TimeProvider.Testing package ships a ready-made FakeTimeProvider; the example writes its own in a few lines.

Spies, and testing outcomes

Prefer asserting on outcomes (what was saved, what was returned, what was sent) over asserting on every call made. A test that pins the exact sequence of internal calls breaks on every refactoring and proves little.

Databases and the web host

EF Core's in-memory provider is not a relational database: it has no transactions, does not enforce foreign keys or unique indexes, and evaluates queries differently from SQL. A test can pass against it and the same code fail against SQL Server. Use a repository fake for unit tests, and a real engine (SQLite in-memory, or the production engine in a container) for tests of data access itself.

For tests of the HTTP surface, WebApplicationFactory<Program> (package Microsoft.AspNetCore.Mvc.Testing) boots the real pipeline in memory and gives you an HttpClient; ConfigureTestServices replaces individual registrations, such as the email sender, with doubles.

Common mistakes

• Reading DateTime.UtcNow or Guid.NewGuid() inside business logic, then writing tests that pass only at certain times of day.
• Treating a green test run against the in-memory provider as proof that queries and constraints work.
• Verifying every interaction with a mock. The test then describes the implementation instead of the behaviour.
• Sharing mutable state between tests through static fields. xUnit creates a new instance of the test class for every test, but statics survive and tests can run in parallel across classes.

What interviewers ask

• What is the difference between a stub, a fake and a mock? Canned answers, a working lightweight implementation, and verified expectations.
• How do you test code that depends on the current time? Inject TimeProvider (or a clock interface) and control it from the test.