Recently I came across this eye opening post on testing.  I’d never thought about there being a fundamental difference in philosophies on testing before.

To be clear, when I write about testing in this post I am thinking specifically about test driven development, which is also what I feel David Christiansen is talking about in his blog post.  Every one agrees you need to test your software.  It’s TDD that becomes divisive.

I’ve talked before about TDD.  Specifically, why I find it hard to adopt.  I admit, I’m still failing at adopting it.  I think there are several factors in this.  One is that I’m working in an established code base that in much of its current state is not amenable to TDD.  There is a lot of tight coupling that is difficult to break.  Only time and effort is going to solve this problem.

Another reason for my failure to adopt it is simply myself.  I haven’t tried very hard.  I haven’t forced myself to try it, so it hasn’t become second nature.  There are things I could do that would probably help me with the adoption.  I could find the tools to put the tests at my finger tips, to integrate them into my environment.  This is my failing to search the tools out.  I just haven’t done it.

What does this have to do with David’s post?  Well, I firmly fall into the first school of testing that David defines: that of using tests to find bugs.  I am not of school number two, that of proving the software performs as advertised.  The more I think about this, the more I feel that TDD is all about school two.  It’s about being able to say that the software does exactly what it is supposed to do.

Is this a bad thing?  No, not in and of itself.  But there seems to be a lot of baggage that comes with this.  A lot of process.  The focus shifts from the application to the process around the application.  I find that many people that buy into TDD are more about the process than the actual development.  So long as there are tests everything is good, even if those tests fail.  There are tests, so something has been accomplished.  It really doesn’t matter what the tests test.  It doesn’t matter if they help to steer the software towards its goal of being a useful application.  There are tests, all is right with the world.

Am I being cynical?  Yes, of course I am.  I’ve just painted an extreme picture.  A somewhat extreme picture.  I think it is reality at a lot more places than people would like to admit.  I’ve found that the longer I develop software, the more I hate processes.  And at this point in my experience, TDD feels like a process.  It’s bloat.

TDD is supposedly about stopping people from making mistakes.  Does TDD succeed in preventing mistakes?  I’m not convinced it does.  I am convinced that it can make an effective club.  When I’m repeatedly beat over the head with the TDD mantra, even when my code works, I feel like it is because I’m not trusted. I don’t think that was the point of TDD, but that is one perversion of it.

In the end, it’s really all a people problem.  David draws the same conclusions.  It’s why we see talk about TDD couched in religious terms.  As David says, “Both schools tend to have a near-religious fervor about their beliefs.”  Machine’s don’t have religions, people do.

I’m going to remain in school one for the foreseeable future.  In the mean time though, I’ll keep trying to make myself adopt TDD.  It’s going to be a slow process, I know that.  Maybe one day I’ll have a conversion experience. I think that day will be the day I realize that TDD keeps me from creating a bunch of new bugs.  So far TDD hasn’t proven it’s any better at that than smart design.  But it has proven it’s good at being a process.

Circling back to what I’ve said once: It’s all a people problem.  Someday we’ll solve it, but in the history of humanity we haven’t proven that we’re very good at it.

That’s really what this blog is about: fumbling my way to solutions of people problems that happen to involve programmers.  Sure, I’ll blog about technology and programming languages quite often, but what are technology and programming languages really, except elaborate solutions to people problems?