What is Test-Driven Development? — A Quick Simple Explanation of the Mindset Behind TDD

Generally, when a request for a feature comes in, you would want to start coding to build it. Later on, you would write your unit tests to make sure that your code was correct.

Test-driven development (TDD) believes that you should create your unit tests first and then write out the code that actually performs the work. It’s essentially about writing your unit tests first and then “filling in the blanks” by writing out the code to make things actually work.

At the core, that’s what TDD is all about. However, many programmers find it a waste of time to create your unit tests first and then let it guide the coding process. Some might think that TDD lengthens the lifecycle of shipping a feature and want to skip writing unit tests altogether in exchange for speed.

Why Write Your Unit Tests First?

Creating your unit tests first helps you to create the “lines and boundaries” for your task. You define what your inputs are going to look like and what your outputs should be. You can clearly think about all of the business requirements before you get to write any code.

Once you have thought of every possible input and output combination, you can start to create the unit tests. Don’t worry about having them fail initially, as we want all the tests to fail to begin with. This is so that as we write the code, we can see which requirements we have met and which ones we have not.

If your code passes all of your unit tests, you can be extremely confident that your code is robust to handle all of the input and output combinations that you thought of. Furthermore, in the future, if someone or yourself ends up having to modify that code, you be sure that if you make a mistake, the tests will catch your error.

The Risk of Not Following TDD

Creating a feature extremely quickly can make it seem like you’re getting a lot of work done quickly. However, without the unit tests, you’re going to run into many problems in the long-term. You’re essentially risking a short-term win for a long-term loss. You may get away with not having any bugs in most of your code, however, the bit of code that does cause a bug may grow into a larger problem. The larger your codebase grows, the higher the probability of these bugs going undetected and causing larger problems.

Think of it this way. Not writing unit tests and quickly deploying your code might give you a boost in the short-term since you could get your feature into production quickly. However, you’re likely to pay back those time gains when some bug is introduced to the codebase and you must track it down.

TDD essentially advocates for short-term pain, taking the extra time to write out unit tests in exchange for long-term gain. That long-term gain is being able to quickly find bugs in new code. It also means that you can sleep well at night knowing that your code is not likely to cause a bug and a huge business problem.

The Mindset for TDD

Another thing to keep in mind about TDD is that you will most likely not see the benefits of TDD for the first couple of weeks following the process. It’s somewhat like going to the gym. Those first two weeks suck and you ask yourself why you are even going through the pain. However, once your new code starts to create bugs and your unit tests start to catch them, you’ll be thankful that you took the time to write those tests out.

Once you start to see how TDD saves you many headaches in the long-run, you’ll start to not want to develop anything in any other way. At first, I used to think that unit testing was a huge waste of time. Why spend another hour writing tests for something that you’re sure is solid code? However, in the long-term, I started to see how the lack of unit tests for my code would lead to extremely complicated bugs because it was hard to track the error source.

I would stay up for quite a bit to track a bug source and push a fix. Now, I just take slightly extra time with each of my commits and include unit tests. In the future, I know that if someone else, or I, change any of that code to incorporate a new feature or modify it, the unit tests will catch any errors we may create. Essentially, as a developer, it gives you peace of mind and helps make your job easier by being able to clearly define the inputs and outputs of a function. From there, the job is just to fill in the blanks.

Conclusion

You may not see the TDD benefits right away; however, they will pay off in the long run. Great minds like Jeff Bezos and Elon Musk advocate for thinking long-term, and TDD is a long-term development strategy.

You get to define the business requirements before you even code any logic, which allows you to essentially “fill in the blanks” with your code. It can also help you find errors quicker whenever refactoring and ensure that the code you are pushing is robust.

What Next?

This article mainly goes over the mindset behind TDD in a simple manner. However, I did not go into detail about how to implement TDD strategically in your project. If you are interested in diving even deeper into the subject of TDD, I recommend this article on FreeCodeCamp that goes into the specifics of TDD.