TDD in .NET: Working with Dependencies (Mocks, Stubs, and Fakes)

You've just written a beautiful test. It's clear, focused, and follows the Red-Green-Refactor cycle perfectly. Then you realize your code needs to send an email, call an external API, or query a database. Suddenly, your tests become:

• 🐢 Slow — waiting for database queries or API responses
• 🎲 Unreliable — network issues, rate limits, or external service downtime
• 🎭 Non-deterministic — data changes between test runs
• 🔗 Tightly coupled — difficult to swap or replace dependencies

"The pain of testing dependencies is feedback. It's your code telling you that your design could be cleaner."

This article will help you understand why dependencies make TDD tricky, what test doubles are (mocks, stubs, fakes), and how they can actually improve your design—not just your tests.

Let's look at a common scenario. You're building a user registration system that sends a welcome email:

public class UserService
{
    private readonly EmailService _emailService;
    
    public UserService(EmailService emailService)
    {
        _emailService = emailService;
    }

    public void RegisterUser(string email, string username)
    {
        // ... validation and user creation logic ...
        
        _emailService.SendWelcomeEmail(email, username);
    }
}
        

How do you test this without actually sending emails? More importantly, should your test care about the email at all, or just that the registration logic works correctly?

This is where Test Doubles come to the rescue. Think of them as stunt performers—they step in when the real thing is too risky, expensive, or slow for practice.

Just like Hollywood has different types of stand-ins (stunt doubles, body doubles, CGI), testing has different types of doubles for different purposes. Let's meet the family:

Let's solve our email problem step-by-step using TDD principles and test doubles.

Step 1: Identify the Problem

Our UserService is tightly coupled to EmailService. This makes it hard to test and violates the Dependency Inversion Principle. Let's fix the design first.

public interface IEmailService
{
    void SendWelcomeEmail(string email, string username);
}

public class UserService
{
    private readonly IEmailService _emailService;
    
    public UserService(IEmailService emailService)
    {
        _emailService = emailService;
    }

    public void RegisterUser(string email, string username)
    {
        // ... validation logic ...
        _emailService.SendWelcomeEmail(email, username);
    }
}
        

Step 2: Write a Test with a Mock

Now let's write a test that verifies the email is sent, without actually sending it:

using Moq;
using Xunit;

public class UserServiceTests
{
    [Fact]
    public void RegisterUser_SendsWelcomeEmail_WithCorrectDetails()
    {
        // Arrange
        var mockEmailService = new Mock<IEmailService>();
        var userService = new UserService(mockEmailService.Object);

        // Act
        userService.RegisterUser("ajay@example.com", "Ajay");

        // Assert
        mockEmailService.Verify(
            e => e.SendWelcomeEmail("ajay@example.com", "Ajay"), 
            Times.Once
        );
    }
}
        

This test is fast, deterministic, and focused. It verifies that UserService correctly calls the email service without actually sending any emails.

Step 3: What About Stubs?

Stubs are useful when you need to control the return values of dependencies. Let's add a feature: users can't register twice with the same email. We need a repository to check for existing users.

public interface IUserRepository
{
    User? FindByEmail(string email);
    void Save(User user);
}

public class UserService
{
    private readonly IEmailService _emailService;
    private readonly IUserRepository _userRepository;
    
    public UserService(IEmailService emailService, IUserRepository userRepository)
    {
        _emailService = emailService;
        _userRepository = userRepository;
    }

    public void RegisterUser(string email, string username)
    {
        var existingUser = _userRepository.FindByEmail(email);
        if (existingUser != null)
            throw new InvalidOperationException("User already exists");
            
        var newUser = new User { Email = email, Username = username };
        _userRepository.Save(newUser);
        _emailService.SendWelcomeEmail(email, username);
    }
}

[Fact]
public void RegisterUser_ThrowsException_WhenEmailAlreadyExists()
{
    // Arrange
    var mockEmailService = new Mock<IEmailService>();
    var mockUserRepo = new Mock<IUserRepository>();
    
    // Stub: Control what FindByEmail returns
    mockUserRepo
        .Setup(r => r.FindByEmail("ajay@example.com"))
        .Returns(new User { Email = "ajay@example.com" });
    
    var userService = new UserService(mockEmailService.Object, mockUserRepo.Object);

    // Act & Assert
    Assert.Throws<InvalidOperationException>(
        () => userService.RegisterUser("ajay@example.com", "Ajay")
    );
}
        

Here, we're using Setup() to create a stub—we're controlling what data the repository returns, not verifying that it was called.

Sometimes you want more realistic behavior without the overhead of real dependencies. That's where Fakes shine. A fake has a working implementation, but it's simplified and in-memory.

public class InMemoryUserRepository : IUserRepository
{
    private readonly List<User> _users = new();

    public User? FindByEmail(string email)
    {
        return _users.FirstOrDefault(u => u.Email == email);
    }

    public void Save(User user)
    {
        _users.Add(user);
    }
}

[Fact]
public void RegisterUser_SavesUser_WhenEmailIsNew()
{
    // Arrange
    var mockEmailService = new Mock<IEmailService>();
    var fakeUserRepo = new InMemoryUserRepository(); // Using a fake instead of a mock
    var userService = new UserService(mockEmailService.Object, fakeUserRepo);

    // Act
    userService.RegisterUser("ajay@example.com", "Ajay");

    // Assert
    var savedUser = fakeUserRepo.FindByEmail("ajay@example.com");
    Assert.NotNull(savedUser);
    Assert.Equal("Ajay", savedUser.Username);
}
        

Fakes offer a middle ground:

• ✅ More realistic than mocks—actual logic, not just assertions
• ✅ Faster than real dependencies—everything stays in memory
• ✅ Reusable across multiple tests

Here's the secret most developers miss: Mocks don't just help you test—they reveal design flaws.

"If your code is hard to test, it's not your tests' fault—it's your design asking for help."

Let's call out some testing sins that even experienced developers fall into:

[Fact]
public void BadTest_MocksValueObjects()
{
    var mockUser = new Mock<User>(); // User is a value object!
    var mockEmail = new Mock<Email>(); // Email is a value type!
    // ... you're testing mocks, not code
}
            

[Fact]
public void BrittleTest_VerifiesInternals()
{
    var mock = new Mock<IEmailService>();
    // ... act ...
    
    // Verifying every single interaction makes tests brittle
    mock.Verify(e => e.Connect(), Times.Once);
    mock.Verify(e => e.Authenticate(), Times.Once);
    mock.Verify(e => e.SendEmail(...), Times.Once);
    mock.Verify(e => e.Disconnect(), Times.Once);
}
            

[Fact]
public void ConfusingTest_InconsistentStubs()
{
    var mockRepo = new Mock<IUserRepository>();
    mockRepo.Setup(r => r.FindByEmail("test@example.com")).Returns(null);
    mockRepo.Setup(r => r.FindByEmail("ajay@example.com")).Returns(new User());
    
    // Test gets confusing—which email are we actually testing?
}
            

Let's compare all three approaches for the same scenario: testing a PaymentProcessor that depends on a IPaymentGateway:

// === Using a Mock (Behavior Verification) ===
[Fact]
public void WithMock_VerifiesPaymentWasCalled()
{
    var mockGateway = new Mock<IPaymentGateway>();
    var processor = new PaymentProcessor(mockGateway.Object);
    
    processor.ProcessPayment(100);
    
    mockGateway.Verify(g => g.Charge(100), Times.Once);
}

// === Using a Stub (State Setup) ===
[Fact]
public void WithStub_ControlsGatewayResponse()
{
    var stubGateway = new Mock<IPaymentGateway>();
    stubGateway.Setup(g => g.Charge(It.IsAny<decimal>())).Returns(true);
    var processor = new PaymentProcessor(stubGateway.Object);
    
    var result = processor.ProcessPayment(100);
    
    Assert.True(result);
}

// === Using a Fake (Realistic Implementation) ===
public class FakePaymentGateway : IPaymentGateway
{
    public List<decimal> ChargedAmounts { get; } = new();
    
    public bool Charge(decimal amount)
    {
        ChargedAmounts.Add(amount);
        return amount > 0; // Simple validation logic
    }
}

[Fact]
public void WithFake_RealisticBehavior()
{
    var fakeGateway = new FakePaymentGateway();
    var processor = new PaymentProcessor(fakeGateway);
    
    processor.ProcessPayment(100);
    processor.ProcessPayment(50);
    
    Assert.Equal(2, fakeGateway.ChargedAmounts.Count);
    Assert.Equal(150, fakeGateway.ChargedAmounts.Sum());
}
        

"Mocks and fakes aren't testing tricks—they're design feedback tools."

Here's what we've learned about working with dependencies in TDD:

1. Dependencies are design feedback

   If your code is hard to test, it's telling you the design needs improvement. Listen to that feedback.

2. Test doubles serve different purposes
   • Mocks → Verify behavior ("Did you call this?")
   • Stubs → Control state ("Here's your data")
   • Fakes → Provide realistic but simplified implementations
3. Great tests focus on behavior, not implementation

   Verify outcomes and contracts, not internal mechanics.

4. Design for testability is good design

   Dependency injection, interface segregation, and single responsibility emerge naturally when you practice TDD.

"Great TDD isn't about avoiding the real world. It's about learning to simulate it—gracefully."

Now that you understand how to handle dependencies, you're ready to tackle more complex scenarios. In the next article, we'll explore:

• TDD in a Web API context with practical examples
• Testing controllers, middleware, and request pipelines
• Balancing unit tests, integration tests, and end-to-end tests
• Building a complete feature using TDD from start to finish

Until then, practice isolating your dependencies and let your tests guide your design!

Have you struggled with testing dependencies before? What strategies worked for you? Share your experiences and questions in the comments below!