DEV Community: Cesare De Sanctis

Test with Moq and AutoFixture

Cesare De Sanctis — Sat, 18 Jan 2025 18:38:46 +0000

In the previous articles of this series, we explored the fundamental concepts of unit testing using handcrafted Test Doubles. We implemented different types of Test Doubles, such as Dummy, Stub, Spy, and Mock.
Now that we’ve covered the basics, understood their importance, and learned how and when to use them, it’s time to elevate our testing strategy.
By leveraging libraries and frameworks widely accepted in the community, such as Moq and AutoFixture, we can simplify the creation of test doubles, enhance maintainability, and reduce boilerplate code. Let’s dive into how these tools work and how their combination can streamline your unit testing process.

What's Moq?

Moq (pronounced "Mock-you" or simply "Mock") is a widely used library for dynamically creating strongly typed Test Doubles. With Moq, you can create Dummies, Stubs, and Mocks "on the fly."

Creating a Dummy with Moq

When you instantiate a Mock object without setting up any behavior for its properties or methods, Moq treats it as a Dummy, returning default values for the invoked methods:

var weatherService = new Mock<IWeatherService>();

Evolving a Dummy into a Stub or Mock

You can configure the behavior of the Mock object to simulate real-world scenarios. For instance:

List<WeatherForecast> expectedForecast = [new WeatherForecast()];
_weatherService.Setup(x => x.GetByCity(_cityWithData))
    .Returns(expectedForecast)
    .Verifiable(Times.Once);

This code configures the GetByCity method to return the expectedForecast list when called with _cityWithData, and ensures the call is verifiable (expected to be invoked exactly once).

Verifying Behavior

At the end of your tests, you can verify if the configured expectations were met:

_weatherService.Verify();

This will throw an exception if the expectations are not satisfied.

Using the Mock Object

You might wonder: "We are working with a Mock<IWeatherService>, but the WeatherForecastController expects an instance of IWeatherService!"

You are right! You can't pass the Mock to the controller constructor, instead you pass the actual IWeatherService object created from the Mock:

_weatherService.Object

Here’s the complete test class demonstrating basic usage of Moq:

public class TestWithMoq
{
    private readonly WeatherForecastController _sut;
    private readonly Mock<IWeatherService> _weatherService;
    private readonly string _cityWithData = "Rome";

    public TestWithMoq()
    {
        _weatherService = new Mock<IWeatherService>();
        _sut = new WeatherForecastController(_weatherService.Object, NullLogger<WeatherForecastController>.Instance);
    }

    [Fact]
    public void Get_ReturnOk_When_Data_Exists()
    {
        List<WeatherForecast> expectedForecast = [new WeatherForecast()];
        _weatherService.Setup(x => x.GetByCity(_cityWithData))
            .Returns(expectedForecast)
            .Verifiable(Times.Once);

        IActionResult actual = _sut.Get(_cityWithData);

        var okResult = Assert.IsType<OkObjectResult>(actual);
        var forecasts = Assert.IsAssignableFrom<IEnumerable<WeatherForecast>>(okResult.Value);
        Assert.NotEmpty(forecasts);
        Assert.Same(expectedForecast, forecasts);
        _weatherService.Verify();
    }

    [Fact]
    public void Get_ReturnNoContent_When_Data_NotExists()
    {
        IActionResult actual = _sut.Get("Paris");

        Assert.IsType<NoContentResult>(actual);
    }
}

In the Get_ReturnNoContent_When_Data_NotExists we are using the Mock object as a Dummy and the GetByCity is returning null.
Moving the setup of the Mock<IWeatherService> from the first test to the constructor of the test class will not change this behavior because the mock will respond null for all input except for "Rome"!

This example highlights Moq’s capabilities to create maintainable and readable tests. For further exploration of Moq’s features, check out the Quickstart on GitHub.

Moq + AutoFixture = ❤️

Introducing AutoFixture

One of the biggest challenges in unit testing is maintaining the tests as your code evolves. Refactoring constructors or adding new dependencies often breaks test compilation, even if the business logic hasn’t changed. This is where AutoFixture comes in.

AutoFixture is a powerful library that acts as a dynamic object factory, generating random yet valid data and objects for your tests. Here are some basic examples:

Fixture fixture = new Fixture();
IEnumerable<WeatherForecast> expectedForecasts = fixture.CreateMany<WeatherForecast>();
string city = fixture.Create<string>();
int random = fixture.Create<int>();

AutoFixture simplifies object creation, letting you focus on the test logic rather than the setup.

Combining Moq and AutoFixture

The magic happens when you mix Moq and AutoFixture.
With the AutoFixture.AutoMoq NuGet package, you can integrate Moq into AutoFixture seamlessly. This allows AutoFixture to create Mock objects and even instantiate your system under test (SUT).

Here’s the refactored test class using AutoFixture and Moq:

public class TestWithAutoFixtureMoq
{
    private readonly IFixture _fixture;

    public TestWithAutoFixtureMoq()
    {
        _fixture = new Fixture().Customize(new CompositeCustomization(
                new AutoMoqCustomization(),
                new ConstructorCustomization(typeof(WeatherForecastController), new GreedyConstructorQuery())
            ));
        _fixture.Customize<DateOnly>(c => c.FromFactory((DateTime dt) => DateOnly.FromDateTime(dt)));
    }

    [Fact]
    public void Get_ReturnOk_When_Data_Exists()
    {
        var expectedForecasts = _fixture.CreateMany<WeatherForecast>().ToList();
        var city = _fixture.Create<string>();

        var weatherService = _fixture.Freeze<Mock<IWeatherService>>();
        weatherService.Setup(x => x.GetByCity(city))
            .Returns(expectedForecasts)
            .Verifiable(Times.Once);

        var sut = _fixture.Create<WeatherForecastController>();

        IActionResult actual = sut.Get(city);

        var okResult = Assert.IsType<OkObjectResult>(actual);
        var forecasts = Assert.IsAssignableFrom<IEnumerable<WeatherForecast>>(okResult.Value);
        Assert.NotEmpty(forecasts);
        Assert.Same(expectedForecasts, forecasts);
        weatherService.Verify();
    }
}

As you can see, we let AutoFixture create all the objects we need, WeatherForecastController included; this way we can make all the changes we want to the WeatherForecastController constructor without the need to change the test code!
This approach ensures that your tests remain resilient to changes in constructors or dependencies.

The only thing we need to do is customize the Fixture object we are gonna use as our "magic object factory":

_fixture = new Fixture().Customize(new CompositeCustomization(
        new AutoMoqCustomization(),
        new ConstructorCustomization(typeof(WeatherForecastController), new GreedyConstructorQuery())
    ));
_fixture.Customize<DateOnly>(c => c.FromFactory((DateTime dt) => DateOnly.FromDateTime(dt)));

With these lines of code we are customizing the fixture with:

AutoMoqCustomization so that AutoFixture knows how to create Moq objects
ConstructorCustomization to customize how the WeatherForecastController will be created. By specifying a "greedy" policy, we ensure that AutoFixture selects the constructor with the most parameters, instead of the default behavior, which picks the one with the fewest. In an ASP.NET Core test context, this is crucial to avoid runtime exceptions, as controllers typically rely on constructors that accept multiple dependencies. Using the "greedy" policy ensures that all required dependencies are properly initialized.
At the end we are customizing how we want a DateOnly value to be created, that is from a random DateTime object.

Now you can follow the code of the test and the only new think that you will find is this line:

var weatherService = _fixture.Freeze<Mock<IWeatherService>>();

The AutoFixture Freeze method will create and freezes the type to always return the same instance whenever an instance of the type is requested either directly, or indirectly as a nested value of other types.

This way, when the _fixture create the WeatherForecastController will use the IWeatherService object coming from the Mock we have already set up.

Advanced Scenarios with AutoFixture

We can further refactor our test, reducing the code, with the power of Theory and AutoData.
The Theory Attribute let you inject data, from different data source, to your test method thurgh method parameter. An example with InlineData could be this:

[Theory]
[InlineData(1, 2, 3)]
[InlineData(4, 5, 9)]
public void Sum(int a, int b, int expectedResult)
{
    int result = a + b;
    Assert.Equal(expectedResult, result);
}

The AutoData Attribute comes from AutoFixture and provide auto generate data from a Fixture. We can create a custom AutoData Attribute to combine the fixture with Moq to enable even more concise and data-driven tests:

public class AutoMoqDataAttribute : AutoDataAttribute
{
    public AutoMoqDataAttribute()
      : base(CreateFixture)
    {
    }

    private static IFixture CreateFixture()
    {
        var fixture = new Fixture().Customize(new AutoMoqCustomization());

        fixture.Customize<DateOnly>(c => c.FromFactory((DateTime dt) => DateOnly.FromDateTime(dt)));

        return fixture;
    }
}

Now we can use AutoMoqData as an attribute and refactor our test this way:

[Theory]
[AutoMoqData]
public void Get_ReturnOk_With_AutoMoqData(
    [Frozen] Mock<IWeatherService> weatherService, 
    [Greedy] WeatherForecastController sut, 
    string city,
    List<WeatherForecast> expectedForecasts)
{
    weatherService.Setup(x => x.GetByCity(city))
        .Returns(expectedForecasts)
        .Verifiable(Times.Once);

    IActionResult actual = sut.Get(city);

    var okResult = Assert.IsType<OkObjectResult>(actual);
    var forecasts = Assert.IsAssignableFrom<IEnumerable<WeatherForecast>>(okResult.Value);
    Assert.Same(expectedForecasts, forecasts);
    weatherService.Verify();
}

You can read more about AutoFixture and all the other integration libraries to the offical documentation page.

Conclusion

Throughout this series, we’ve explored foundational and advanced unit testing concepts, starting with handcrafted Test Doubles and progressing to Moq and AutoFixture. These tools empower developers to:

Write tests that are easier to read and maintain.
Reduce boilerplate and focus on test logic.
Handle changes in dependencies with minimal friction.

Mastering unit testing is an ongoing journey. With tools like Moq and AutoFixture, you can build a robust, maintainable test suite that supports your applications’ growth.
Start applying these concepts today and elevate your testing strategy!

Test with Spy and Mock

Cesare De Sanctis — Fri, 03 Jan 2025 15:45:39 +0000

In the previous article, we tested our WeatherForecastControllerusing a Dummy logger and a Stub service. While this was sufficient for basic unit testing, in this article, we'll take our testing to the next level by introducing Spies and Mocks.

As an exercise, we want to evolve our unit tests to use Spy and Mock. These kinds of Test Doubles let us have more control over what the code does since we can assert how many times a method is called, which values are passed to a method, and much more.

Let's see a basic implementation of each.

Spy

As you may remember from the first article of the series, a Spy is like a Stub but with the added ability to record information about how methods are called—such as which parameters are passed and how many times the method was invoked. This makes it useful for assertions and verifications at the end of the test.

With this in mind, evolving the Stub service into a Spy is straightforward and may look like this:

internal class SpyWeatherService : IWeatherService
{
    private readonly List<WeatherForecast> _weatherForecast =
        [
            new WeatherForecast
            {
                Date = DateOnly.FromDateTime(DateTime.Now),
                TemperatureC = 20,
                Summary = "Test Summary"
            }
        ];

    public int NumberOfCalls = 0;
    public string LastRequestedCity = string.Empty;

    public IEnumerable<WeatherForecast> GetByCity(string city)
    {
        NumberOfCalls++;
        LastRequestedCity = city;
        return string.Equals(city, "Rome") ? _weatherForecast : Enumerable.Empty<WeatherForecast>();
    }
}

We have simply added two properties:

NumberOfCalls, to store the number of times GetByCity is called
LastRequestedCity, to store the last input passed to GetByCity

Tests with Spy

The constructor for our test class looks like this:

public class TestWithSpy
{
    private readonly WeatherForecastController _sut;
    private readonly SpyWeatherService _weatherService;
    private readonly string _cityWithData = "Rome";

    public TestWithSpy()
    {
        _weatherService = new SpyWeatherService();
        _sut = new WeatherForecastController(_weatherService, new DummyLogger<WeatherForecastController>());
    }
}

Using the XUnit Framework and initializing the WeatherForecastController in the constructor of the test class is very important when working with Test Doubles because XUnit calls the test class constructor before each test. This way, we ensure that an instance of _sut (System Under Test) is not shared between tests. This allows us to use the properties we introduced in the Spy to make assertions across multiple tests, knowing they reset for each test!

At this point, we can change our tests to look like these:

[Fact]
public void Get_ReturnOk_When_Data_Exists()
{
    IActionResult actual = _sut.Get(_cityWithData);

    var okResult = Assert.IsType<OkObjectResult>(actual);
    var forecasts = Assert.IsAssignableFrom<IEnumerable<WeatherForecast>>(okResult.Value);
    Assert.Equal(1, _weatherService.NumberOfCall);
    Assert.Equal(_cityWithData, _weatherService.LastRequestedCity);
    Assert.NotEmpty(forecasts);
}

[Fact]
public void Get_ReturnNoContent_When_Data_NotExists()
{
    IActionResult actual = _sut.Get("Paris");

    Assert.IsType<NoContentResult>(actual);
    Assert.Equal(1, _weatherService.NumberOfCall);
    Assert.Equal("Paris", _weatherService.LastRequestedCity);
}

While checking the number of method calls or the last requested city might seem trivial in this case, these assertions become invaluable as our logic grows more complex. They allow us to verify not just the final outcome but also the correctness of interactions within our system.

Mock

Now that we've seen how a Spy can help us track method calls and parameters, let's take it a step further with Mocks, which allow us to define stricter expectations and enforce them during the test.

Mocks are particularly useful when testing interactions with dependencies that should follow strict contracts, such as ensuring an API is called a specific number of times or with exact parameters.

From the first article of the series, a Mock takes the concept of a Spy one step further: it can be pre-programmed with expectations about method calls, such as which parameters should be passed and how many times the methods should be invoked. If these expectations are not met, the Mock can throw an exception. Mocks usually include a Verify method to assert that the expectations were satisfied.

An implementation for the IWeatherService that matches this definition could be the following:

internal class MockWeatherService : IWeatherService
{
    private readonly Dictionary<string, List<WeatherForecast>> _expectedResponses = [];
    private readonly List<string> _calledWithCities = [];

    public void SetUpGetByCity(string city, List<WeatherForecast> weatherForecasts)
        => _expectedResponses[city] = weatherForecasts;

    public void VerifyGetByCity(string cityToVerify, int times = 1)
    {
        var actualCount = _calledWithCities.Count(x => x == cityToVerify);
        if (actualCount != times)
            throw new Exception($"GetByCity to be called {times} time(s) with city {cityToVerify}, but was called {actualCount} time(s).");
    }

    public IEnumerable<WeatherForecast> GetByCity(string city)
    {
        _calledWithCities.Add(city);
        return _expectedResponses.TryGetValue(city, out List<WeatherForecast>? value) ? value : Enumerable.Empty<WeatherForecast>();
    }
}

We have defined two fields:

_expectedResponses is a dictionary used to set up the expected response returned by the GetByCity method for a given city. The SetUpGetByCity method will be used for the set up and is a utility method not part of the IWeatherService interface.
_calledWithCities is a list that will store strings passed to the GetByCity method during a test and used by another utility method, VerifyGetByCity, to verify the expectations on the mock.

Tests with Mock

Using the MockWeatherService, our test class looks like this:

public class TestWithMock
{
    private readonly WeatherForecastController _sut;
    private readonly MockWeatherService _weatherService;
    private readonly string _cityWithData = "Rome";

    public TestWithMock()
    {
        _weatherService = new MockWeatherService();
        _sut = new WeatherForecastController(_weatherService, new DummyLogger<WeatherForecastController>());
    }

    [Fact]
    public void Get_ReturnOk_When_Data_Exists()
    {
        List<WeatherForecast> expectedForecast = [
            new WeatherForecast()
        ];

        _weatherService.SetUpGetByCity(_cityWithData, expectedForecast);
        IActionResult actual = _sut.Get(_cityWithData);

        var okResult = Assert.IsType<OkObjectResult>(actual);
        var forecasts = Assert.IsAssignableFrom<IEnumerable<WeatherForecast>>(okResult.Value);

        Assert.Same(expectedForecast, forecasts);

        _weatherService.VerifyGetByCity(_cityWithData);
    }

    [Fact]
    public void Get_ReturnNoContent_When_Data_NotExists()
    {
        IActionResult actual = _sut.Get("Paris");

        Assert.IsType<NoContentResult>(actual);
        _weatherService.VerifyGetByCity("Paris");
    }
}

The code is self-explaining but I want you to focus your attention to

List<WeatherForecast> expectedForecast = [
            new WeatherForecast()
        ];

and this line

Assert.Same(expectedForecast, forecasts);

As you can see, we are initializing a non-empty list with an empty WeatherForecast. Since its properties are not relevant for our tests, we only care that the instance returned by GetByCity is the same one returned by the Controller’s Get method without further data manipulation. This is where junior developers tend to overcomplicate things—keep it simple!

What’s Next?

That's all for a basic implementation of Test Doubles in scope for the series.
In the next article, we'll explore how Moq and AutoFixture can further simplify our test setup, making our tests both faster to write and easier to maintain.

Stay tuned!

Test with Dummy and Stub

Cesare De Sanctis — Fri, 27 Dec 2024 14:45:16 +0000

Let’s put theory into practice and start testing! In this article, we’ll focus on two types of Test Doubles — Dummy and Stub — to fully test our WeatherForecastController. Ready? Let’s dive in!

Dummy

As we can see from the previous article, the WeatherForecastController has two dependencies: the IWeatherServiceand the logger.

Although logging is important, we decided that "we don't care" about the logging part of the code. With this in mind, the logger becomes a good candidate for a Dummy since it is only needed for the Controller initialization, and we can't pass null to the constructor otherwise, at some point during the test, we would get an exception when the logger is called.

As you may remember from the first article of this series, a Dummy is an object that does nothing. The implementation of a Dummy for ILogger<WeatherForecastController> could look like this:

internal class DummyLogger<T> : ILogger<T>
{
    public IDisposable? BeginScope<TState>(TState state) where TState : notnull
        => null;

    public bool IsEnabled(LogLevel logLevel)
        => false;

    public void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception? exception, Func<TState, Exception?, string> formatter)
    {
    }
}

Pretty easy, right? Just let Visual Studio implement the interface and return some default values where needed.

Can you spot the pattern? This is an implementation of the Null Object Pattern, which ensures that we don’t run into null reference errors during testing while keeping the code clean and focused on what we’re testing.

Tip: You can have a null logger for free using the NullLogger<T> in the Microsoft.Extensions.Logging.Abstractions namespace.

Stub

Now we need an implementation of the IWeatherService:

public interface IWeatherService
{
    IEnumerable<WeatherForecast> GetByCity(string city);
}

with fixed response to predefined input.
Here we go:

internal class StubWeatherService : IWeatherService
{
    private readonly List<WeatherForecast> _weatherForecast = 
        [
            new WeatherForecast
            {
                Date = DateOnly.FromDateTime(DateTime.Now),
                TemperatureC = 20,
                Summary = "Test Summary"
            }
        ];

    public IEnumerable<WeatherForecast> GetByCity(string city)
        => string.Equals(city, "Rome") ? _weatherForecast : Enumerable.Empty<WeatherForecast>();
}

With this implementation, we are sure that we can get a non-empty list when we pass "Rome" as the input to the GetByCity method.

Now we can create the WeatherForecastController using the Dummy logger and the Stub service. With this in place, unit testing the GET method becomes straightforward.

Tests

As a reminder, this is the method we want to test:

[HttpGet("{city}")]
public IActionResult Get(string city)
{
    var data = _weatherService.GetByCity(city);
    if (data.Any())
        return Ok(data);

    _logger.LogInformation("No data found for {City}", city);

    return NoContent();
}

We know that "Rome" is the input for the GetByCity method to return some results, and we can make this information explicit in a variable in our test class, which looks like this:

public class TestsWithStub
{
    private readonly WeatherForecastController _sut;
    private readonly string _cityWithData = "Rome";

    public TestsWithStub()
    {
        _sut = new WeatherForecastController(
            weatherService: new StubWeatherService(),
            logger: new DummyLogger<WeatherForecastController>());
    }
}

Following the code of the Controller, we want our first test to assert that we can get an Ok response with weather data when they are available, and we know they are for the input "Rome". Here's the code using XUnit:

[Fact]
public void Get_ReturnOk_When_Data_Exists()
{
    IActionResult actual = _sut.Get(_cityWithData);

    var okResult = Assert.IsType<OkObjectResult>(actual);
    var forecasts = Assert.IsAssignableFrom<IEnumerable<WeatherForecast>>(okResult.Value);
    Assert.NotEmpty(forecasts);
}

We use Assert.IsType<OkObjectResult> to ensure the response type is correct, and Assert.IsAssignableFrom<IEnumerable<WeatherForecast>> to validate the returned object structure.

The second and last test will assert for a NoContent response when no data is available:

[Fact]
public void Get_ReturnNoContent_When_Data_NotExists()
{
    IActionResult actual = _sut.Get("Paris");

    Assert.IsType<NoContentResult>(actual);
}

We have fully tested our WeatherForecastController!

What’s Next?

In the next article, we'll evolve the StubWeatherService, making it a Spy and exploring what we can do with it.

Stay tuned!

What we will test

Cesare De Sanctis — Mon, 23 Dec 2024 11:54:12 +0000

It’s time to dive into the code!

To keep things simple, we’ll be testing a slightly modified version of the famous Visual Studio Weather Forecast web API template.

Here’s the code:

[ApiController]
[Route("[controller]")]
public class WeatherForecastController : ControllerBase
{
    private readonly ILogger<WeatherForecastController> _logger;
    private readonly IWeatherService _weatherService;

    public WeatherForecastController(IWeatherService weatherService, ILogger<WeatherForecastController> logger)
    {
        _weatherService = weatherService;
        _logger = logger;
    }

    [HttpGet("{city}")]
    public IActionResult Get(string city)
    {
        IEnumerable<WeatherForecast> data = _weatherService.GetByCity(city);
        if (data.Any())
            return Ok(data);

        _logger.LogInformation("No data found for {City}", city);

        return NoContent();
    }
}

Although we’re not doing TDD here, it’s important to understand that if we were, we’d test this controller using the London school of TDD. This approach is outside-in and behavior-driven.

The key idea is this: we don’t care how the concrete implementation of the WeatherService works or what it does.
The only thing we know — and care about — is that it returns an IEnumerable<WeatherForecast>. That’s enough for us! In fact, we won’t create a concrete implementation of the IWeatherService interface at all.

Here’s what the IWeatherService interface looks like:

public interface IWeatherService
{
    IEnumerable<WeatherForecast> GetByCity(string city);
}

And here’s the WeatherForecast class that comes pre-generated by Visual Studio:

public class WeatherForecast
{
    public DateOnly Date { get; set; }

    public int TemperatureC { get; set; }

    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);

    public string? Summary { get; set; }
}

With this setup, we’re ready to start testing! First, we’ll explore how to test using Dummy, Stub, Spy, and Mock objects. Later, we’ll dive into powerful libraries like Moq, AutoFixture, and AutoFixture.AutoMoq to streamline our tests.

We won’t consider using a Fake as a Test Double in our examples. Typically, Fakes include logic to simplify complex systems, such as an in-memory database replacing a real database. However, given the simplicity of the code we’re testing, creating a simplified implementation of IWeatherService would be unnecessary and out of scope.

What’s Next?

In the next article, we’ll test this controller with:

A Dummy logger, because we’ve decided that “we don’t care” about the logging part.
A Stub WeatherService, which will help us simulate the behavior of the IWeatherService.

Stay tuned!

Not everything is a Mock, let's explore Test Doubles

Cesare De Sanctis — Wed, 18 Dec 2024 08:53:13 +0000

Generative AI can be a blessing for junior developers, as long as they understand that the answers these tools provide should be a starting point — a springboard for diving deeper into a new topic, framework, or design decision.

However, I often see the opposite, especially when it comes to unit testing and test-driven development (TDD). Many junior developers today rely on last-driven development, powered by ChatGPT. While leveraging AI isn't inherently bad — after all, productivity is key — problems arise when developers copy-paste code without truly understanding it. This lack of comprehension makes it hard to discuss the "why" behind their code with their team or debug effectively when things go wrong.

That's why I decided to start this series. If you're doing unit testing and you think everything is a mock, then you're in the right place! I'll explain the differences between test doubles and guide you on a journey from a more "purist" testing strategy to practical tools like Moq, AutoFixture, and AutoMoq.

What are Test Doubles?

Test Double is a generic term coined by Gerard Meszaros for any object that replaces a real implementation during testing.

Think of a Test Double like a stunt double in a movie: it "stands in" for the real object during unit testing when the real object is unavailable, doesn't exist yet, is too complex, or is undesirable to use in a test scenario. The primary goal of a Test Double is to help you isolate the unit of code you're testing.

The 5 Types of Test Doubles

There are five types of Test Doubles, and we will explore them with simple and practical examples in the upcoming articles. For now, let’s define them one by one.

Dummy

A Dummy is the simplest Test Double. It does nothing—it’s only passed around to satisfy a method or constructor’s parameters but is never actually used.

Example: You might pass null or an empty object to a constructor when the parameter is not relevant to the test.

Stub

A Stub provides fixed and predictable responses to method calls. This is useful when you want the test to produce consistent and controlled outcomes.

Example: Returning a predefined value from a database query or a service call.

Spy

A Spy is like a Stub but with the added ability to record information about how methods are called—such as which parameters are passed and how many times the method was invoked. This makes it useful for assertions and verifications at the end of the test.

Example: Assert that a method was called a specific number of times with the expected parameters.

Mock

A Mock takes the concept of a Spy one step further: it can be pre-programmed with expectations about method calls, such as which parameters should be passed and how many times the methods should be invoked. If these expectations are not met, the Mock can throw an exception. Mocks usually include a Verify method to assert that the expectations were satisfied.

Example: Using a mocking framework like Moq to ensure a service method was called with specific inputs.

Fake

A Fake is a simplified but working implementation of a real object. Unlike Mocks or Stubs, Fakes actually contain some logic, but they often include shortcuts or less complex behavior compared to the real object. A common example is an in-memory database that replaces a real database for testing purposes.

Example: An in-memory repository that stores data in a list instead of connecting to an actual database.

In the next articles, we'll explore the different types of Test Doubles with practical C# examples—starting from a "purist" approach and progressing to the use of libraries such as Moq and AutoFixture.

Stop saying that Test-Driven Development is just a testing methodology!

Cesare De Sanctis — Tue, 15 Oct 2024 09:06:04 +0000

Test-Driven Development is one of the core disciplines of Extreme Programming and is fundamental for developing quality software. I often find myself talking to young developers approaching unit testing reluctantly, as it’s usually imposed by management, often because a certain percentage of code coverage is required. They hear about TDD as a means to achieve 100% code coverage. But is it just about writing tests before code, or is there more to it?

In this article, we’ll explore the real purpose of TDD and why you should consider it as more than just a testing technique.

What is TDD?

Before diving into the real reasons for adopting TDD, let’s quickly recap what it is. Test-Driven Development is a development methodology where tests are written first, followed by the code necessary to pass them. The typical TDD cycle follows three main phases:

Red: Write a test for a functionality that doesn’t exist yet. The test will fail because the functionality hasn’t been implemented.
Green: Write the minimum amount of code required to make the test pass.
Refactor: Optimize and clean up the code without changing its behavior, keeping the tests passing.

Repeating this cycle, with discipline, for every new feature helps keep the code tested and clean. However, TDD isn’t just about writing tests. Now let’s look at the main reasons you should consider adopting this practice.

The Myth: TDD to Write Perfect Tests

One of the most common myths surrounding TDD is that its main purpose is to ensure the code is fully tested. It’s true that Test-Driven Development forces you to write tests before code, which improves code coverage, but the primary reason teams adopt it goes far beyond mere testing.

TDD is less focused on the test results and more on how it influences the development process. Tests are a means, not the goal.

The Real Purpose: Improving Code Design

The real benefit of TDD lies in how it changes your approach to code design. TDD pushes you to think about how your code will be used before writing it. How?

1. Usage-Oriented Design

By writing the test first, you immediately put yourself in the shoes of someone who will use a function or class. This naturally leads you to define simpler APIs, more cohesive modules, and clearer objects. It’s like asking yourself, "How do I want the code to behave?" before implementing it.

2. Reducing Complexity

If you adhere to the discipline and rules imposed by TDD, you write exactly the code necessary to pass a test, nothing more. The result is a reduction in complexity and a focus on solving one problem at a time.

Since TDD encourages constant iteration, large, monolithic, and complex blocks of code are avoided. The Red-Green-Refactor cycle forces you to break the problem into small parts that can be addressed one at a time. As the Latin phrase goes, "divide et impera".

3. Overcoming the Fear of Changes

Thanks to the broad test coverage that TDD provides, the old dev mantra "If it works well enough, don’t touch it" loses its meaning. Any feature can be rewritten or modified without fear of introducing bugs or regressions, as you have a quick way to verify the new code — just run the tests!
Software maintenance will become much easier in the long run.

4. Simplifies Debugging

When you use TDD, you don’t always need to manually test every change, and when a bug arises, it immediately becomes a candidate for a new test. This makes the debugging process more organized:

Write a test that exposes the bug
Write code to fix it

In this way, every fix is immediately verified, and you can be sure the bug won’t reoccur.

Conclusion: TDD as a Design Tool

At this point, you’ll agree with me that TDD isn’t just a discipline that improves code but it also enhances your approach to development. It forces you to think, approach problems incrementally, and reduce problem complexity by breaking it down into smaller parts.

The real value of Test-Driven Development doesn’t lie solely in ensuring your code is tested, but in the better design it promotes. TDD guides you towards a more structured and modular approach, compelling you to carefully consider how to design the code before writing it.

Start viewing TDD not just as a testing method but as a way to develop cleaner, more maintainable, and robust software. Writing tests before the code forces you to think better, create leaner code, and improve its overall quality.

The next time you ask yourself, "Do I really need to write tests before the code?" remember that it’s not the test that matters, but the quality of the design that results from it.

Let me know what you think of TDD. Have you ever tried adopting it in your workflow? How did it go? Do you have any tips for introducing TDD to teams where testing is seen as solely the responsibility of the QA team?