Why You Should Do Test Driven Development (TDD)

4 min read

embertdd

Are you the type of developer who, when starting a task, seeks to only get a general idea of the work in your head before immediately starting to code? If so, doing Test Driven Development (TDD) might seem like a waste or time, or not worth the effort. Until recently, that was my way of thinking. 

But whether you are working on a small personal project or a large corporate application, I would argue that TDD is the best way to think about how you code. Here are five reasons why:

1. TDD Results in More Efficient Code

When you start by writing your tests up front for any task you find yourself working on, you will often find yourself asking a lot more questions than normal about how each particular piece needs to function and look. This is excellent, because it forces you to have a more robust scope of the work before you start coding. Additionally, it helps you not forget about certain edge cases in the process. 

As a result, your code is more likely to be more efficiently written and easily maintained.

2. TDD Improves QA

At companies I’ve worked at in the past, we had employees whose job it was to test all the features that developers had written. While a QA team is still a great thing to have if your budget can afford it, a lot of the bugs they found, in our case, were things that tests would have prevented.

However, when your code is test driven, many times, your QA team is likely only to find CSS issues having to do with browser intricacies. Because you’ve written tests that ensure the desired functionality, the only functional issues are going to be things you didn’t think to write tests for (Which can be quickly remedied).

3. TDD Prevents Breaking Changes

Have you ever implemented a feature in your app, only to find out it broke something else? Have you ever deployed that feature not realizing that new bug was present?

By writing thorough tests in your application, you will be aware when something breaks. As a result, you will be able to catch mistakes, preventing users and clients from being the ones to do so.

4. TDD Saves Your Reputation

How many applications, which had great ideas, are now extinct because of countless bugs in the code? Quite simply, too many to count.

By writing tests that verify functionality, and enable you to catch mistakes before they get deployed, your users and clients will be less likely to find bugs in your work. As a result, your reputation will be that of a reliable developer, and your apps will be both less likely to break and more likely to succeed.

5. TDD Is How You Already Think

Lastly, a coworker of mine recently made a profound statement about TDD. He said, “you already write tests in your head, so why not actually write them in your code?”.

What he meant was, when you look at a feature you need to write, you first start by asking questions like, “What does this need to do?”, “What result do I expect?”, or “What happens if I use it the wrong way?”. What you may not know is, the answers to those questions are the script to use in your tests! So why not take a few moments before you start coding to write out those expectations that will need to be checked?

Go Forth

Now, I do not claim to be an expert in Test Driven Development, but the more I do it, the more I enjoy it. In some ways, it makes my work feel like a little game of “Let’s make all the tests pass”, and when that happens, my work is done, and I can move on to the next item on my list.

If you haven’t taken TDD for a test drive yet, but are interested in doing so, look for some good articles on getting started using your development stack. If you have any questions or need some pointers, feel free to hit me up on Twitter. I’d love to chat!