Writing tests represents one of those few stages of software development that is usually overlooked, even though it may be one of the most important one. Developers mention it and usually are either uncomfortable and prefer not to write tests for their code, or have many excuses for not writing them at all.
Well, tests are important:
- A software bug in a Therac-25 radiation therapy machine caused the death of five patients after receiving a massive dose of X-rays.
- Knight Capital lost half a billion dollars in half an hour when a software bug allowed computers to sell and buy millions of shares with no human oversight.
These and many other stories tell how seemingly unimportant bugs can actually cause so many tragic disasters.
We know how critical software is becoming to every area of our lives. We know that the security, stability and correctness of this software has a crucial importance in our lives. So the question is: why do developers still avoid writing tests?
Excuse #1: “Writing tests just takes too much time.”
It’s easy to perceive writing tests as taking too much time, as opposed to jumping directly into the implementation part.
This may be true in the short term, but if we take into consideration the time you may potentially need to fix all the bugs you could avoided by writing tests, then writing tests can actually save time — and even money — along the way.
Tests do not eliminate bugs completely (nothing can do that), but they can dramatically reduce them. They can even make you feel more confident that you’re not breaking any existing functionality when you add new features and refactor old ones.
Tests also help you save time and protect your existing implementations from inexperienced programmers who recently joined your team. If these newcomers introduce bugs, your tests will fail. And when your tests fail, you become aware that something went wrong.
Project managers who lack a programming background — and thus may not understand the programming complexities that may arise all of a sudden — tend to have high expectations of the developers on their teams. They want to things done quickly, and fast production-ready code. They may consider it unreasonable to postpone a strict deadline.
These situations may put you into tough situations — where you have to choose between following best practices or getting things done quick-and-dirty.
You should try and find a few professional principles you can stick to no matter what. You should try your best to convince your manager of the importance of best practices, and how they pay off in the long run. And if your manager can’t be convinced, then you may consider changing jobs.
Excuse #2: the fear of writing tests
It’s no surprise that developers spend most of their working hours either reading code, writing code, or discussing new problems to solve with code. As a result, they have a very strong emotional attachment to it, and prefer to treat it as their precious property.
Many are confident that they’re already experienced enough, and that they are capable of covering every possible scenario without much effort.
On the inside, they may harbor a sense of insecurity. And subjecting their code to tests may cause that insecurity to flare up.
Maybe they pushed their code changes to the master branch faster than they should have, because they want to look like a productive employee to their manager. And now they’re afraid that writing tests might reveal bugs in their code. They’re afraid of being exposed as average programmers who cannot write bug-free code.
Well, we should all do ourself a favor and never let our own sense of ego delude us into not writing tests. As uncomfortable as it may feel, we should take responsibility for our own work. This is one of the best ways to avoid bugs — bugs which can often have tragic consequences.
Tests allow you to make big changes in your code quickly, since you can be confident that everything is working correctly. When you’re used to writing tests for your code, you will then usually be able to finish off your work a lot faster, as you will have instant visual feedback when something is failing as you will see a red light. As a result, you will also write better code, feel less stress, and eventually get promoted, as you’re ultimately bringing in more value with the work that you are doing.
Make time for testing
Tests will never be able to catch 100% of bugs, but they will contribute to the security, stability and correctness of your code. Make time for them.
Thanks for reading. If you found this article helpful, please click the 💚 below, so that other people can hear and benefit from it as well.
I am currently looking for a remote Ruby on Rails job. Please contact me for new opportunities.