Click here to Skip to main content
15,918,268 members
Articles / DevOps / Unit Testing

Test-induced Design Damage or Why TDD is So Painful

Rate me:
Please Sign up or sign in to vote.
4.78/5 (13 votes)
3 Aug 2015CPOL4 min read 34.5K   12   30
Test-induced design damage or why TDD is so painful

I'm going to write a couple of posts on the topic of TDD. Over the years, I've come to some conclusions of how to apply TDD practices and write tests in general that I hope you will find helpful. I'll try to distill my experience with it to several points which I'll illustrate with examples.

Test-induced Design Damage

I’d like to make a quick note before we start. TDD, which stands for Test-Driven Development, is not the same thing as writing unit tests. While TDD implies the latter, it emphasizes test-first approach, in which you write a unit test before the code it tests. In this article, I’m talking about both TDD and writing tests in general. I also refer to both of these notions as “TDD” for the sake of brevity, although it’s not quite accurate.

Have you ever felt like adhering to the TDD practices or even just unit testing your code after you wrote it brings more problems than solves? Did you notice that, in order to make your code testable, you need to mess it up first? And the tests themselves look like a big ball of mud that is hard to understand and maintain?

Don’t worry, you are not alone. There was a whole series of discussions on whether or not TDD is dead, in which Martin Fowler, Kent Beck, and David Heinemeier Hansson tried to express their views and experiences with TDD.

The most interesting takeaway from this discussion is the concept of test-induced design damage introduced by David Hansson. It generally states that you can’t avoid damaging your code when you make it testable.

How is it so? Let’s take an example:

C#
[HttpPost]
public HttpResponseMessage CreateCustomer([FromBody] string name)
{
    Customer customer = new Customer();
    customer.Name = name;
    customer.State = CustomerState.Pending;
 
    var repository = new CustomerRepository();
    repository.Save(customer);
 
    var emailGateway = new EmailGateway();
    emailGateway.SendGreetings(customer);
 
    return Ok();
}

The method is pretty simple and self-describing. At the same time, it’s not testable. You can’t unit-test it because there’s no isolation here. You don’t want your tests to touch database because they’d be too slow, nor do you want them to send real emails every time you run the test suite.

In order to test business logic in isolation, you need to inject the dependencies to the class from the outside world:

C#
public class CustomerController : ApiController
{
    private readonly ICustomerRepository _repository;
    private readonly IEmailGateway _emailGateway;
 
    public CustomerController(ICustomerRepository repository,
        IEmailGateway emailGateway)
    {
        _emailGateway = emailGateway;
        _repository = repository;
    }
 
    [HttpPost]
    public HttpResponseMessage CreateCustomer([FromBody] string name)
    {
        Customer customer = new Customer();
        customer.Name = name;
        customer.State = CustomerState.Pending;
 
        _repository.Save(customer);
        _emailGateway.SendGreetings(customer);
 
        return Ok();
    }
}

Such an approach allows us to isolate the method’s business logic from external dependencies and test it appropriately. Here’s a typical unit test aimed to verify the method’s correctness:

C#
[Fact]
public void CreateCustomer_creates_a_customer()
{
    // Arrange
    var repository = new Mock<icustomerrepository>();
    Customer savedCustomer = null;
    repository
        .Setup(x => x.Save(It.IsAny<customer>()))
        .Callback((Customer customer) => savedCustomer = customer);
 
    Customer emailedCustomer = null;
    var emailGateway = new Mock<iemailgateway>();
    emailGateway
        .Setup(foo => foo.SendGreetings(It.IsAny<customer>()))
        .Callback((Customer customer) => emailedCustomer = customer);
 
    var controller = new CustomerController(repository.Object, emailGateway.Object);
 
    // Act
    HttpResponseMessage message = controller.CreateCustomer("John Doe");
 
    // Assert
    Assert.Equal(HttpStatusCode.OK, message.StatusCode);
    Assert.Equal(savedCustomer, emailedCustomer);
    Assert.Equal("John Doe", savedCustomer.Name);
    Assert.Equal(CustomerState.Pending, savedCustomer.State);
}

Does it seem familiar? I bet you created plenty of those. I did a lot.

Clearly, such tests just don’t feel right. In order to test a simple behavior, you have to create tons of boilerplate code just to isolate that behavior out. Note how big the Arrange section is. It contains 11 rows compared to 5 rows in both Act and Assert sections.

Why TDD is So Painful

Such unit tests also break very often without any good reason – you just need to slightly change the signature of one of the interfaces they depend upon.

Do such tests help find regression defects? In some simple cases, yes. But more often than not, they don’t give you enough confidence when refactoring your code base. The reason is that such unit tests report too many false positives. They are too fragile. After a time, developers start ignoring them. It is no wonder; try to keep trust in a boy who cries wolf all the time.

So why exactly does it happen? What makes tests brittle?

The reason is mocks. Test suites with a large number of mocked dependencies require a lot of maintenance. The more dependencies your code has, the more effort it takes to test it and fix the tests as your code base evolves.

Unit-testing doesn’t incur design damage if there are no external dependencies in your code. To illustrate this point, consider the following code sample:

C#
public double Calculate(double x, double y)
{
    return x * x + y * y + Math.Sqrt(Math.Abs(x + y));
}

How easy is it to test it? As easy as this:

C#
[Fact]
public void Calculate_calculates_result()
{
    // Arrange
    double x = 2;
    double y = 2;
    var calculator = new Calculator();
 
    // Act
    double result = calculator.Calculate(x, y);
 
    // Assert
    Assert.Equal(10, result);
}

Or even easier:

C#
[Fact]
public void Calculate_calculates_result()
{
    double result = new Calculator().Calculate(2, 2);
    Assert.Equal(10, result);
}

That brings us to the following conclusion: the notion of test-induced design damage belongs to the necessity of creating mocks. When mocking external dependencies, you inevitably introduce more code, which itself leads to a less maintainable solution. All this results in increasing of maintenance costs, or, simply put, pain for developers.

Summary

Alright, we now know what causes so-called test-induced design damage and pain for us when we do TDD. But how can we mitigate that pain? Is there a way to do this? We’ll talk about it the next post.

Other Articles in the Series

The post Test-induced design damage or why TDD is so painful appeared first on Enterprise Craftsmanship.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
United States United States
.NET software developer, software architect, DDD evangelist

Comments and Discussions

 
QuestionI am not sure I agree either with the code being untestable or design injection Pin
NukeDuke5-Aug-15 6:22
NukeDuke5-Aug-15 6:22 
QuestionRe: I am not sure I agree either with the code being untestable or design injection Pin
Thomas Eyde8-Aug-15 0:35
Thomas Eyde8-Aug-15 0:35 
QuestionThis article is flawed. Pin
Chris Marisic5-Aug-15 6:01
Chris Marisic5-Aug-15 6:01 
QuestionRe: This article is flawed. Pin
Thomas Eyde8-Aug-15 0:54
Thomas Eyde8-Aug-15 0:54 
QuestionI agree: Mocks are the problem.. Pin
Mike Parker25-Aug-15 0:46
Mike Parker25-Aug-15 0:46 
AnswerRe: I agree: Mocks are the problem.. Pin
Vladimir Khorikov5-Aug-15 1:19
Vladimir Khorikov5-Aug-15 1:19 
GeneralRe: I agree: Mocks are the problem.. Pin
Mike Parker25-Aug-15 3:08
Mike Parker25-Aug-15 3:08 
GeneralRe: I agree: Mocks are the problem.. Pin
Thomas Eyde8-Aug-15 1:04
Thomas Eyde8-Aug-15 1:04 
SuggestionDoes TDD Breaking Design? Pin
Elio R. Batista Gonzalez4-Aug-15 10:22
Elio R. Batista Gonzalez4-Aug-15 10:22 
GeneralRe: Does TDD Breaking Design? Pin
Vladimir Khorikov4-Aug-15 10:49
Vladimir Khorikov4-Aug-15 10:49 
GeneralRe: Does TDD Breaking Design? Pin
Elio R. Batista Gonzalez4-Aug-15 11:06
Elio R. Batista Gonzalez4-Aug-15 11:06 
QuestionI think you have too much coupling between customer and EmailGateway Pin
Brian J Rothwell4-Aug-15 10:13
Brian J Rothwell4-Aug-15 10:13 
As a minimum, i think an EmailGateway should deal with Emails, not Customers.
AnswerRe: I think you have too much coupling between customer and EmailGateway Pin
edmolko5-Aug-15 4:11
edmolko5-Aug-15 4:11 
GeneralTDD helps code design Pin
Seb Carss4-Aug-15 5:00
Seb Carss4-Aug-15 5:00 
GeneralRe: TDD helps code design Pin
Vladimir Khorikov4-Aug-15 5:17
Vladimir Khorikov4-Aug-15 5:17 
GeneralMy vote of 5 Pin
Camilo Reyes4-Aug-15 4:21
professionalCamilo Reyes4-Aug-15 4:21 
GeneralRe: My vote of 5 Pin
Vladimir Khorikov4-Aug-15 5:18
Vladimir Khorikov4-Aug-15 5:18 
GeneralRe: My vote of 5 Pin
Thomas Eyde8-Aug-15 1:16
Thomas Eyde8-Aug-15 1:16 
QuestionSo far I agree Pin
Paul Tait4-Aug-15 3:57
Paul Tait4-Aug-15 3:57 
AnswerRe: So far I agree Pin
Vladimir Khorikov4-Aug-15 4:00
Vladimir Khorikov4-Aug-15 4:00 
QuestionYou might wanna proofread the article. Pin
Jeremy Falcon3-Aug-15 11:39
professionalJeremy Falcon3-Aug-15 11:39 
AnswerRe: You might wanna proofread the article. Pin
Vladimir Khorikov3-Aug-15 11:44
Vladimir Khorikov3-Aug-15 11:44 
GeneralRe: You might wanna proofread the article. Pin
Jeremy Falcon3-Aug-15 11:51
professionalJeremy Falcon3-Aug-15 11:51 
GeneralRe: You might wanna proofread the article. Pin
Vladimir Khorikov3-Aug-15 12:40
Vladimir Khorikov3-Aug-15 12:40 
GeneralRe: You might wanna proofread the article. Pin
Thomas Eyde8-Aug-15 1:18
Thomas Eyde8-Aug-15 1:18 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.