Where I Am With TDD

25 January, 2008. 536 words.

Test Driven Development is one of the buzzwordy things that Agile and Extreme programmers like to push as the most important programming advancement since sliced bread. (Although, recently, TDD seems to be losing out in favor of a new thing called Behavior Driven Development (BDD), which as far as I can tell is the exact same thing as TDD, except instead of naming your tests “TestWidgetProperty,” you name your tests “Determine_if_the_widget_property_is_working_correctly.” (That is a humorous observation not meant to be taken seriously.))

Anyway, if you don’t know, Test Driven Development mandates that you write test cases for your code before writing the actual code. I’ve tried it, but I personally find that writing the tests first is quite boring and sucks every bit of fun out of software development, so I usually work on unit testing either during or after coding, or (gasp!) not at all. (Where I work, I’m fortunate enough to be under no obligation to program in any particular way.) Whenever I write tests, it’s usually when I don’t feel very creative, as writing unit tests feels very dull and repetitive to me. TDD proponents would find this anywhere from wrong to dangerous to outrageously heretical.

But don’t get me wrong - I like unit testing. Whenever I write tests, I invariably find and fix bugs, and the stability of my code improves; there’s no doubt about that. And, as you can see at right, there is that certain satisfaction you get from seeing your tests light up in green after you make a major change. I’m just saying it’s not the end-all, be-all that some would have you believe, and it’s certainly no substitute for plain old job experience. In fact, I think there might be an argument to be made that excessive testing encourages intellectual laziness during development: Instead of thinking out what kind of consequences your changes are going to make, with a battery of tests at your disposal, you can just make changes willy-nilly, run your tests and look for green lights or red lights to see if your change was “good” or “bad.” I’m not saying everyone does that, but it seems like a bad thing that could happen. That’s just my opinion, of course.

Right now, I mainly use unit testing to exercise the mechanics of an API or object interface. (Which, you could say, is the very definition of unit testing.) For example, if I want to make sure that my class throws an exception if the caller tries to set a property wrong. I also test to make sure that calculations are done correctly. I’m working on an accounting application where I’ve written a number of tests to make sure my objects compute credits and debits properly.

However, I don’t find unit tests very convenient for testing high-level functionality. Part of me feels that if the underlying objects are tested thoroughly, the higher-level stuff will take care of itself. The other part of me just hates writing unit tests that are more lines of code than the actual application. One of my programming goals this year is to work more with mocks and interface testing, mainly just so I can give them a fair evaluation.

Related