I'm Not Sure When It Happened, but Now I Like TDD
By: Joel Stauffer
Learning About Test-Driven Development
To be fair, though, my instruction on TDD was delivered by two seasoned developers who knew the “whys” and “hows” that make the practice useful. For their credit, these developers are Jon Fazzaro (currently) of Aptera, and Bob Martin (affectionately known as Uncle Bob by many of his fans). I received the grand tour of the three steps, the most valuable targets of testing, some pairing on a couple of katas, the practicality of using mocks, and instruction on the use of language to illustrate the purpose of a program.
Of course, my first impression of TDD was, “Okay, this is what ‘they’ do ‘here’ and if I expect this internship to go well, I have to learn it.” It started with a couple videos, a FizzBuzz kata, some Q&A, and then eventually some shiny new production code. I’m not sure when it happened, but now I like TDD. Honestly, what hooked me on the practice wasn’t the tests at all. It was what the tests allowed me to do that locked me in.
I spent the first week of my internship watching Bob Martin showcase the height of clean code. A demonstration of short functions, descriptive names, proper boundaries, extensive extractions, dependency inversions, and others I’ll omit for brevity, had my programmer’s mind itching for that clean code. But it’s all a gimmick, the minute a programmer’s finger hits a key the code becomes dirty. No surprise here—humans naturally write imperfect code on their first attempt. The only way the code can be restored to a clean state is through constant refactoring and that isn’t practical without tests.
“Wait, can an intern say that? He’s got no idea what the professional world is like!” Well, yes, if that’s you screaming into your device: you’re not wrong. Coming on with 6 years of programming practice doesn’t make an expert in anything. But I’ve watched projects small and large descend into chaos and I know that isn’t sustainable for an individual or a company. TDD is the only solution I can see that gives me the confidence to instill my organizational mindset into the code I write. Without a suite of fast tests, I can’t make any change to working software and have an adequate confidence it is going to work in any end user application.
But this is hardly the end of my TDD story, but rather a barely manifested beginning.
Time will tell whether I continue the practice. I am not immune to the troubles that have routed the practice from other developers. Ridiculous deadlines, frustration, poorly designed tests, and other unknown obstacles stand in my way that will either derail my TDD practice or temper it. I hope to look back on this experience as the beginning of my professional career, and not with the regret of having dropped a practice that solves a host of naturally occurring problems.
About Joel Stauffer
Joel Stauffer is a senior at Purdue University Fort Wayne studying computer science and spent the summer of 2018 as a Software Development Intern at Aptera. He has experience writing programs in C# and building Android mobile apps. When he’s not coding, Joel enjoys spending time outdoors kayaking, ice-fishing, hiking, and hunting for morel mushrooms.