by , April 30, 2024
When I first heard about Test-Driven Development (TDD) back around the turn of the century, I admit I was a little hesitant. It seemed like a lot of extra work.
Was it, really?
I started programming forty years ago, and grew up with what I’ll charitably call “printf-Driven-Development,” or PDD. This was the age of C programming, and in C the print statement is printf(3)). In PDD, you sprinkle print statements throughout the code, dumping out critical values of variables and the ever-present “GOT HERE” messages to trace program execution. You run the code, and visually inspect the output checking that the printed values meet your expectations.
There’s nothing wrong with that technique, and I admit to using still to this very day (literally, I just used it today when working on a systems integration issue where a separate test wasn’t feasible). But, it’s manual and error prone. We can do at least a little better.
So the next step up from PDD is a simple unit test. Unit tests are the exact same thing as PDD, except that you write code to check the values and progress instead of reading over the output yourself. Okay, that seems a reasonable step forward—and clearly a time saver. Yes, it may take a little more time upfront to write the code that checks the variables and state. But then that code can run pretty much instantaneously compared to me sitting there scrolling through reams of output over and over and over again. And that test code won’t miss a potential problem like my tired eyes might.
I was very consistent in my use of unit tests at the time, but didn’t jump right into Test-Driven Development whole heartedly for one simple reason: I didn’t know what I wanted the code to to.
And there’s the rub.
Test-Driven Development is a design technique, not a testing or even implementation technique (although it has fantastic side effects in those areas). In fact, I often call it Test-Driven Design. It’s a small step from printf-Driven-Development to unit tests—you’re just automating what you’re already doing, and it quite clearly saves time and leads to more accurate results.
But it’s not a small step from unit tests to TDD, it’s a giant step. It’s a giant step because you have to know what you want before you start writing code. And it seems a lot of the time, that’s maybe not the case.
Perhaps your’e working with a new library or framework, or poorly-documented 3rd-party API. You may not know what to expect, so you write some code and see what happens. That’s fine, and sometimes that sort of exploration is really the only option.
But sometimes the reason you don’t know what you want is because you haven’t really thought about. So you slap some kinda-maybe code together and see what happens using PDD, then make adjustments to your code and your expectations.
And that’s the crippling flaw with Test-Driven Development: it requires you to think.
—
Follow @growsmethod in the Fediverse, or subscribe to our mailing list:
Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.