Repeat after me: Test Driven Development is about design, NOT testing!

A few weeks back while listening to .NET Rocks Episode 408, I cringed so badly when I started hearing Dr. James Whittaker, who is, apparently, in charge of Visual Studio Team System's testing tools (which I surmise includes the oft-admonished MS Unit Testing framework), talk about test driven development and his gripes about it.

Right then and there I saw it: Microsoft's attitude about test driven development has been totally wrong, precisely because they were asking the worst possible person about it. Whittaker is the worst person to talk about test driven development, because he's focused on testing.

Microsoft failed to understand, outright, that test driven development is NOT about testing.

Scott Bellware responded to Whittaker's statements via the Hanselminutes podcast, wherein he offered The Last Word On Test Driven Development on Episode 164. There, he questions (at around 5:30 into the podcast) "why test-driven development is coming out of a conversation about software quality and software quality tools":

I think it's quite sad though that no matter [how much we tell people] that TDD is about design rather than testing, that it never really sank in...

Questions about software quality are damaged when we let them fall over into conversations about test driven development...

The goal with [TDD] isn't really a unit testing goal although we're borrowing unit testing tools to achieve the goal... [We're almost like] "demonically" possessing unit testing to achieve other needs.
["The Last Word on TDD" on Hanselminutes]

I said as much when someone asked on Stack Overflow whether TDD takes focus away from design. In my response, I stated that it's precisely the opposite -- that, once again, TDD is all about software design:

If done right, Test Driven Development IS your design tool.

[...]

Test Driven Development, done right, should make developers highly aware of design pitfalls like tight coupling, violations of DRY (don't repeat yourself), violations of SRP (Single Responsibility Principle), etc.

If you write passing code for your tests for the sake of passing your tests, you have already failed: you should treat hard to write tests as signposts that make you ask: why is this done this way? Why can't I test this code without depending on some other code? Why can't I reuse this code? Why is this code breaking when used by itself? ["Does TDD take away focus from design?" on Stack Overflow]

The reason why I don't take this misconception lightly is because this realization came to me the hard way -- I was part of a project wherein Test Driven Development was grossly misunderstood by previous members of the project:

There was... a failure to recognize that TDD is not about tests, it's about design. The rampant case of singleton abuse in the unit tests made this obvious: instead of the test writers thinking "WTF are these singleton = value; statements doing in my tests?", the test writers just propagated the singleton into the tests. 330 times.

The unfortunate consequence is that the build server-enforced testing was made to pass, whatever it took["When TDD goes red" on Dotnet @ Kape ni LaTtEX]

The attitude Microsoft took regarding this issue explains a lot why testing is an add-on "luxury" feature to Visual Studio, which you pay extra for, and not part of its core features out-of-the-box, and on top of that made it definitely illegal to implement in Visual Studio Express. Hiring a testing expert to implement a software design engineering guide lead to the inevitable misrepresentation of the value of TDD.

Unfortunately, treating TDD as a luxury feature gives the impression to hobby and professional software developers alike that test driven design is nothing but a bell and a whistle in Visual Studio -- which it is not. Test driven development is a paradigm in software development, and to many it has become a fundamental way of ensuring that code for software of any size and complexity is flexible and maintainable and remains that way.

So repeat after me: TDD is about design. It's NOT about unit tests. Tell that to the every developer who asks what TDD is all about, and to every developer who thinks TDD is about testing.

About Jon Limjap

Jon Limjap has been programming since he was 12 and hasn't stopped yet. He was gone for a while in iOS and Java land, but is now back in .NET searching for unicorns and hunting down dragons.
This entry was posted in Tech Musings and tagged , , , , , , , . Bookmark the permalink.

7 Responses to Repeat after me: Test Driven Development is about design, NOT testing!

  1. AaronC says:

    I couldn’t agree more. The mounting misconceptions about TDD are a constant source of teeth-grinding for me.

    This is one of the most aspects of BDD I find most attractive. In addition to clarifying where/how someone should start testing, it also removes the word “test” from the discussion.

    I think we’re still a ways from having an authoritative BDD framework for .Net, but the progress the BDD guys are making in ruby space seems quite promising.

  2. Chris says:

    While I agree TDD is about design and not testing, most times, you don’t have a choice in the real world. I’m happy enough to just have tests and have people to write tests. I’d love the tests to be written and done first, but I’ll take what I can get in corporate envirnments where it’s all about “is it done yet” and “we’re releasing on xx-xx-xxx”.

  3. Jon Limjap says:

    AaronC,

    Makes me all the more excited about IronRuby. :)

    Chris,

    Indeed. I admit that many, many times I myself failed on test-first and sprinted my way to finishing features in my applications instead of going test first, and many times I only add tests later after bugs have already appeared.

  4. Samuel says:

    That is because TDD is not applicable in most cases in the real world. When a customer ask you to quote the development cost of a certain application you can’t tell him that…uhmmm….you will be using TDD and that it will take time to develop “quality” code for the project.

    That is just too expensive!

    One more thing, maintaining two to sets of code is expensive. And who get to tests the TESTS?

  5. Jon Limjap says:

    Samuel,

    There’s a balance that has to be struck to make the best out of TDD, in that it should be used to determine the malleability of the code in question (the design part). It shouldn’t be used to test every nook and cranny of code for the sake of being 100% coverage complete.

    So who tests the tests? That’s really the wrong question here: the correct question is, do the tests describe the specifications of the project? They should… and if they don’t, then the tests aren’t really useful.

  6. Samuel says:

    Jon,

    I agree with your comment about balance.

    >> So who tests the tests? That’s really the wrong question here
    No, I believe that my question is correct.

    >> he correct question is, do the tests describe the specifications of the project?
    It seems to me that you write 100% bug-free tests and boy, that makes you an exception! That is a compliment.

    But for me, writing tests is still writing code and must be verified by someone other than the developers that’s why we have a QA department to do this for us.

  7. Jon Limjap says:

    Samuel,

    LOL! I didn’t say that I don’t get bugs on my tests. I do have a lot of them, and that’s the reason that for any given time I have a lot of tests on the Ignore attribute. :P

    And definitely this is not an issue of “Quis custodiet ipsos custodes?”

    QA is totally another issue. Automated unit tests do not mean that QA becomes indispensible. Going back to what Scott Bellware said above:

    Questions about software quality are damaged when we let them fall over into conversations about test driven development…

    -Jon

Comments are closed.