How far should you apply TDD?

Question

I see the benefit of TDD, and I'm trying to learn how to wrap my head around it. I'm also reading more about DDD and want to start applying both of them to my software projects.

I've purchased a few "hands on" programming books (by "hands on" I mean ones that discuss a real world application with real solutions as opposed to small snippets) and I've noticed that they typically start defining the "infrastructure" layer of the application in traditional code-first fashion, as opposed to using TDD; both books go out of their way to discuss how good TDD is and how the case study will make use of it.

For example in one of the books, ASP.NET 3.5 Social Networking, the entire second chapter develops a Logging wrapper class, an Email wrapper class, Cache and Session wrapper classes (and their associated interfaces) all without touching upon a single unit test. Another book, .NET Domain Driven Design with C#: Problem, Design, Solution does similar, and creates a base class and repository framework code-first before even touching on the "real" code.

I understand that you should test the actual logic and functionality of your domain classes. I had thought the "don't test plumbing" code only applied to code that you didn't write (e.g. built-in .NET classes), but what I'm reading seems to indicate/suggest that you should only test the code that actually has to do with your application and not the plumbing that you write to provide a foundation.

Is this an acceptable way of applying TDD?

Answer 1

I am no expert here.

But if you are developing plumbing components, it should be tested.
If I understand correctly, with TDD, code written against interface & in absence of plumbing components, people use Mock objects.

Answer 2

I went into this at some length in another question. Basically, the point of using TDD and mocks and all that stuff is to develop more confidence.

Answer 3

When learning TDD, apply everything. Afterward, apply what you need.

Answer 4

If you are writing the plumbing from scratch then you should have tests around it. If you are just using a few interfaces and classes to abstract away your linq2sql calls then, no I wouldn't necessarily put unit tests around that.

To quote someone smarter than I:

I’m not religious about TDD. I consider it a discipline worth following. I don’t write all my tests first. Some small number of them are simply more convenient to write after the code. There is even some code I don’t write tests for at all, because it’s just not worth it. But those are exceptions to the rule. The vast majority of the code I write, I write test first.

-uncle bob martin via: http://www.infoq.com/news/2009/02/spolsky-vs-uncle-bob

Answer 5

TDD should be applied to any code that you develop. When using TDD you needn't test everything -- i.e., the goal isn't 100% coverage -- but coverage should be pretty high over code that you develop. For example, you don't need to test automatic gettor/settors in C# -- you can trust that the language will do it's job there. When in doubt, though, write the test first.

Answer 6

It probably depends on other factors about how you plan to build your project.

If you're following other Agile practices, such as small iterations and deliveries, then you won't have much of an architecture or infrastructure at the start, because you won't have time to develop much while you're implementing and delivering the first few features. Anyway, why spend time on Big Design Up Front, when you don't really know what the code is going to need?

So you'll build your code test-first and over a number of iterations. Test coverage means you can refactor to improve your design, which (in theory) allows exactly the right the infrastructure to emerge for the application as it exists at any moment in time. Ron Jeffries explains it well here. Without the tests, you're probably going to hit a point where you need to stop and figure out what the structure should be, which is going to take time that could better be spent building useful features and that you're going to have to test at the end anyway.

If you're 100% certain you can map out the design correctly before you have written any code, then it's your choice to do so. Make sure to leave plenty of time in the project for testing, though. I think everyone should build at least one significant piece of work both by the "traditional" Waterfall process and by just diving in and coding in order to have some experience that puts the Agile practices into context. Otherwise you're at risk of knowing "what" without knowing "why", and that makes the lessons harder to learn.

Answer 7

By all means write code-first to gain experience with a platform - just be brave and throw it away once you're sure you can tackle most tasks on that platform. I've just done that with a small Java program I've started.
Now that I've gained some experience I can see what I have to do to get very high line coverage now that I'm starting to write it test-first, even most of the plumbing.

Answer 8

If you test some code, and don't test other code, which code will have the bugs?

Hint: it's the untested code.