After speaking with Jean-Paul Boodhoo earlier this week, I'm convinced more than ever that I need to tread carefully into TDD waters. In my previous post on the subject, I think I came down harder than I intended, attacking the example more than the method.

It's not the paradigm-shift itself that gives me pause. After all, we're software developers. Paradigm shifts are what we do. Writing tests first? Sure, why not. If that's what the methodology says, that's what I'll do. I can see the benefit of it pretty easily. And frankly, there are already cases where I write code for methods that don't exist yet, although they are never unit tests.

What I want to be careful about is how I write these tests. This is where I can see frustration setting in. Again, the one test = one method is a simple enough rule to follow. But how granular do you make that method? How much should it do? How do you account for other potential clients for that method that may require changing the signature? (These are rhetorical questions; no need to flood my inbox with e-mails saying “it depends“.)

Fortunately, I believe this is a learned skill. Just like OO is a learned skill. The difference is that I spent years in university learning OO in a structured environment. This I have to learn on my own. And it's not like picking up a new framework that you can use Intellisense to explore and try things out. Some real live thought has to be put into what you're doing.

The other complication for me is that TDD encourages interface-based programming. This isn't as bad because while I haven't done a lot of it personally, it's something I can wrap my head around and can muddle my way through fairly easily.

The ultimate point of this post is basically the same as the original one: I'm interested enough that I want to figure out how to do it properly. My overall opinion has changed ever-so-slightly, though, in that it's probably something I would use somewhat regularly if I knew how to do it. Maybe not as the be-all and end-all of every project but like any good methodology, it's good to understand it so you can recognize when it's a good fit.

I still think there's something to this Conscientious Coding idea, though.

And JP, if you're reading, next lunch will be down at my neck of the woods. Best to come outside hurricane season.