5 reasons why testing code is great

Developers are an odd bunch. We agree that best practices should be followed at all times. Right? Then we get to testing. Some developers love writing tests and some go out of their way to avoid it. I just wanted to list a few reasons why you should most definitely write tests.

1. They save you hours of debugging.

When you have tests that your code needs to pass, you’re preventing bugs from creeping through. You won’t be able to finish a task on your list until you write code that passes the test. That way, when it’s time to make that pull request, you won’t get complaints from other developers on your team, and you’ll be submitting higher quality code.

You’ll catch all of those little things, like syntax errors or the wrong values getting passed, that sometimes make it to the next phase in your pipeline. After you’ve written a bunch of code for an application, it will take you longer to find those small things compared to finding them immediately with your unit tests.

2. They make you think about your code before/as you write it.

Since you have to write each unit test, you really have to understand what the functionality is supposed to do – it gets rid of most ambiguities that you get from user stories or general requirements. When you are writing the code for a unit test, you have to know everything about what you’re testing.

What parameters should you expect? Why are you writing the code in a specific way? How do you think the user could break the code? All of these questions come up when you are writing unit tests, and you have to have an answer. By the time you finish a certain task, you’ll know everything about the nuts and bolts behind it.

3. They make you write efficient code the first time.

Eventually, your tests will get you to stop writing lazy code because you will grow tired of them failing and of you having to refactor code all the time. Unit tests force you to write good code from the beginning, which means your first round of code will be relatively efficient, you won’t have to go through all those hours of debugging, and you’ll have more readable code.

Writing unit tests helps to keep your code simple because you write just enough code to pass the test. Having simple, easy to read, bug-resistant code in your first round of programming makes you more confident as a developer, and it makes your employers have more confidence in you.

4. They give you documentation for the application.

A unit test is a small piece of code that describes a user story or some kind of requirement. Over time, all of those small pieces of code add up to tell the story of how the entire application works. When a different developer hops on to this project, they will be able to go through the tests and see what every part of the code does and why.

This can be the best source of documentation you could ever wish for. When new bugs crawl out or you need to add new features, you’ll have a way to make sure none of your changes break any current functionality. You’ll also have a way to find out where you should start debugging or building new functionality.

5. They help keep deployments smooth.

Because you have written a test for most of the functionality in the application, you can catch any last-minute issues before you deploy it with both unit and integration tests. There will be times when you merge everyone’s code together and something somewhere deep in the code breaks. When you don’t have either of these tests in place and you’re supposed to have the changes deployed before the next day, you could spend hours panicking and searching for the issue.

However, it’s a completely different story when you do have testing in place. If there is something broken in the code after a merge, the tests will most likely find it and tell you what’s wrong. Then, your panic time might only be a few minutes instead of hours. This last-minute check can save you a lot of problems with clients and managers. It’s better to be able to tell them that you know what the problem is versus not knowing anything and saying it worked on your machine.

These are a few of the reasons I write as many tests as I can. Sure, it takes more time in the beginning, but it makes a Friday night deployment a whole lot better.

Hey! You should follow me on Twitter because reasons.