How far should you apply TDD? [closed]

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

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

Answer 2

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