[ Content | View menu ]

TDD: It’s A People Problem

Mark Mzyk | March 5, 2008

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?

One Comment

  1. Comment by Tom R:

    I think the fundamental purpose of QA is risk management. Both groups of people are fundamentally wrong – because they miss a basic reality. Perfect code is obsolete code. It simply isn’t economically effective to produce perfect code – so QA exists to ensure that while it may be imperfect, at least its useful.

    During my first month as a QA Engineer, I bumped heads with my peers many times over defects. Fundamentally, I’m the type of person who believes that if you find a bug – then it should be fixed. Their argument was that bugs should only be fixed when the benefits out way the potential problems. An unfortunate example of this happened last year when a newly hired development engineer “fixed” something in common code – causing chaos as all the modules which had “worked around” the problem broke. After a week it was decided to give up trying to sort out the mess and just revert the dev-tree.

    As far as the second class of software testing, which relates to specs, I’m very wary of those types of developers and testers. If you have a perfect spec – then great. This is something you which is so rare you may never experience it. However, what happens when the spec is worthless and the only way you can create a decent product is to abandon it entirely. This recently happened on one of our products – the spec was abandoned because the person who wrote it didn’t know anything about how to make a decent web product.

    As far as TDD – I’m probably in the skeptical camp. If anything, I believe in DDT – development driving testing. The idea that I’ll experiment with a solution before settling on it. Test driven development causes too much lock-in. The earlier you write a test case, the more likely you will have to change or drop the test before it has a positive ROI (Return on Investment). So much of this depends on what you are developing.

    A developer can never prove more then Happy Path testing, since they can never know what false assumptions they have about how others may view the product. The invisible wall between QA and Engineering exists for this very reason. We may encourage Engineers to test their code, but we certainly don’t believe them when they say it won’t break.

    March 7, 2008 @ 23:18