An Old Dog Learns a New TDD Trick

Do you think that Test Driven Development is worth it? It was for me!

If you’ve been in the software development industry for a long time like me, you are faced with new methodologies, technologies, and other “ologies” that you are encouraged (or forced) to learn. You accept it because it’s part of the profession we’re in. Things change – sometimes for better, others for worse – but progress happens, nonetheless. While it can be difficult, seeing new ways of solving problems is exciting.

The Method of Test Driven Development

A perennial problem that everyone faces is how to build software efficiently. There are ways to organize projects to streamline the process, help organize your thoughts on how your product should work and execute the construction of the project. One question everyone must face is: “How do we know when we are done?”

The obvious answer is: “When the product meets the project criteria.” This can be a vague goal. A more finite goal is to use a design methodology consisting of writing unit and integration tests to verify that what you wrote works as you expect. The proper order is to write the tests first, then the application code, and then use the tests to validate your work. This is called Test Driven Development (TDD), and the idea has been around for a long time. Here’s a great description of it: https://www.browserstack.com/guide/what-is-test-driven-development

Theory vs. Reality

In Theory, TDD is a good idea. But . . . many of us don’t want to spend the up-front time doing it. We already have our ideas for building the product, and – especially when there’s an established timeline involved – we want to get working on the actual application. “Writing tests ahead of time takes time away from development,” we tell ourselves. “I don’t have time for that – the project is due soon” or “I’ll write tests after development,” knowing this hardly ever happens. This has been me many times over the years, and not just limited to the three above statements. We agree with the theory, but it remains just a theory. We think we know better.

We all like the idea of working on something completely new, but we’re often making modifications to existing products instead. When doing so, one of the dictums on your mind is (or should be) “leave it better than you found it.” But how do you go about doing that? Certainly, you don’t want to break something that is working correctly. Without any existing automated testing, you’re left with the always-subjective testing by the developer. 

TDD in the Wild

I was recently working on a project that was in development and needed to make a surgical modification to a critical process. The initial engineer had written many integration tests, and as I worked on my changes, the lightbulb went on in my brain about the value of these tests. I made several assumptions in my design that the integration tests poked holes in. The existence of the tests shortened the development time by giving me an immediate response on whether my changes worked or broke anything previously working. Though I didn’t write them, I was operating in a TDD environment and now experienced the value of pre-written tests.

On the same project, I had another surgical modification to make, but there were no tests covering this process this time. Having seen the value of tests, I started by writing all the integration tests to cover the processing scenarios my change needed to handle. Then I started actual development. I’m not going to say it was easier, nor do I have quantifiable data to show it was quicker, but I believe that my development phase was indeed shorter. Because I had written my definition of “done”, I knew when my code was functioning correctly. In addition, all the other previous tests helped because I was kept from breaking something previously working.

TDD Works

I’ve become a believer in Test Driven Design. I’ve just scratched the surface of working in a TDD environment, but I’m living proof that it is possible to teach an old dog a new trick. So, if you’re in that camp that I was in where you don’t feel like you have the time, give it a serious try. I think you’ll find that in the long run, you’ll be saving time for yourself and the developer who comes after you.

Want More?

Are you excited to learn more about testing strategies and try out TDD for your next project? Check out Kevin Bost’s blog A Guide to Practical Unit Testing – Shift Left or Mike Curn’s blog, Painless Bug Testing through the Isolation of Variables, for more examples and inspiration.