Main consumer of the unit test suite is a developer himself. That's right! You are writing these tests for yourself. To be more precise you are writing them for your-future-self. It's one of these things that pays dividend later down the road, and here is why.
At some point you will get back to the piece of code you committed and you will scratch your head, thinking what this thing even does. You want to be able to go to the test suite and find out what it was doing.
If your next task is a bug to be fixed - you don't want to commit the fix just for the next person to remove your change because it seems to be nonsense. You want to put unit test that proves the bug is fixed, because you don't want to spend time on this bug again. To quote Google's Beyoncé Rule "If you liked it, then you shoulda put a test on it".
There is good chance that your day-to-day work requires a lot of thinking. There is also good chance that you spend a lot of time reading code. What would you rather read, a piece of code where you have no idea of what set of inputs/outputs are possible, or would you like to read executable spec that tells you exactly what happens under what circumstances? This executable specification is called unit test.
Occasionally your users might start to complain about slowness of your code, or SRE team can come to you and say that you use way too much RAM. This means that you need to get your hands dirty, play with that profiler and make your feature performing better. This is when you will thank yourself that your feature is tested because you can improve (refactor) your code easily - as long as tests pass - you are sure that you didn't break anything with your performance improvement.
When you are writing a piece of library - you want to interact with what you've done. If your API is easy to use - you will taste it in your tests. If it's hard to use it - you will feel the pain just as the user of your API will feel the pain. You want to have this microscope and look at your code from outside world. As it turns out - unit test is a terrific tool for that.
From time to time someone might ask you - hey, what this piece of code is doing? Being able to answer - "hey, just look at the unit tests - they will tell you what is what" is an asset you want to have.
Ability to run the program is very cool. Let's say you want to run a piece of code that lives deep in your repository. How do you do it? If your answer is - I am running the whole application, plug in the debugger (or print some values), and play with it from outside - you are in the disadvantage. Better way is to have a unit test that allows you to run any piece of the code you have in your repository without providing any external dependencies. It saves your time. It's your ally in day to day work. If you need to click through the UI or send some messages to the queue just to execute a piece of code - you should know that there is a better way.
Not only you are a programmer, but you are code reviewer from time to time as well, right? If this is the case, I bet that instead of guessing what are possible inputs and edge cases of given function it's better to read the test suite, and learn more about the piece of code you are reviewing. Not only that, tests allow you to better understand what is the intention of given piece of code. And if you know what is the intention you can review not only correctness of the code but you are able to judge whether things are named properly - which is very important given that this code will be read by many people in the future.
On top of that you are making sure that software you deliver does exactly what it should, and you can prove it easily, quickly and repeatedly.
Are there any more reasons to start writing unit tests?
Top comments (0)