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 the other developers on your team and you submit 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 the application, it will take you longer to find those small things compared to finding them immediately with your unit tests.
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 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.
They make you write efficient code the first time.
Eventually your tests will get you to stop writing lazy code because you get tired of them failing and you needing to refactor code all the time. Unit tests force you to write good code from the beginning which means your first round of code is 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 you 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 too.
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 are breaking any current functionality. You’ll also have a way to find out where you should start debugging or building new functionality.
They help keep deploys 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 them with both unit and integration tests. There will be times 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, searching for the issue.
It’s a completely different story when you have testing in place. If there is a 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 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.
Those are a few reasons I write as many tests as I can. Sure it takes more time in the beginning, but it makes a Friday night deploy a whole lot better. What are your thoughts on writing unit tests?
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding