During my time as a developer, I have come across wildly differing opinions on testing. Many would say that you absolutely, without a doubt, should write tests around the code you write. Others felt that testing was a waste of the developer’s time and energy.

When I first began programming, I did not like writing tests. It was my least favorite part of programming. I mean, come on, my code is working, now I am supposed to go back and write tests too? No, thanks! Little did my naive self know that tests would soon make my life as a developer a whole lot easier.

When I learned to write tests before writing code (Test-_Driven_ Development, or TDD) , I soon realized that by writing my tests first I was actually writing less code.

Does this mean I was previously writing unnecessary code? Was I making my code more complex than it needed to be? Yes. Yes, I was.

Test driven development to me is not just about testing and reliability, but about design. Writing a test first allows me to organize my thoughts, and focus on the things I need, and what I am trying to accomplish. Writing tests first naturally leads to less coupling in my code.

I have experienced benefits of having and writing tests around code, but still, many of my current coworkers had a less than warm fuzzy feeling when it came to testing. It was only a matter of time.

Recently, a new team was formed which included myself and two other developers. We had a new task. We were to add new functionality to two different systems. No members of our team had experience with the first system. So how do we get started? We need to implement the new functionality but not, I repeat, do not break the existing functionality.

How do we start implementing code safely if we don’t know what is already existing? I’ll tell you how: we studied the tests. In about 15 minutes we went from knowing just about nothing about the system to knowing the type of services it used and what it was supposed to do. This was enough knowledge to get us going and feel safe enough to change things!

All we had to do was read the test names. How easy was that? So simple, yet, so valuable! On to the second system. Now lucky for us, one of our team members had worked on the code for this system a year and some change ago. But wait, it had been so long that he really couldn’t remember how it really worked. That’s okay, we will just run the tests. Oh no! There are no tests. We could not possibly start working as we had no idea how things worked. We also were lacking the safety to experiment because how would we know if we broke something? Long story short, it took us a day and a half to read through the code, try to understand what was going on and where we needed to start. Something that had previously taken us 15 minutes, turned into over 10 hours. Spending all that time just trying to decipher code really took a lot out of us. By the time we could finally start coding we were so low energy, we weren’t really working at the best of our ability. We felt dragged down. Now where is the wasted energy?

I hope my story will inspire others to give test-driven development a fair chance. It is so helpful both in the process of developing, and also when you are dealing with existing code. We felt so much appreciation to those developers who came before us. They took the time to write tests. Those developers saved us time, effort, and energy that we were able to use in implementing new functionality. By the way, we ended up writing tests around the untested code we modified. We build our own safety net to allow us the space to experiment. This was the best way for us to feel confident and safe about making changes. Now, hopefully, those developers who will come next can benefit from those tests. Who knows, maybe the next developers will be us.