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. 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.

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.

When we know how much computer programs are widely becoming part of every part of our lives and that their security, stability and correctness has a crucial importance in our lives, the question that arises is: Why developers still avoid writing tests?

Testing is an area of development where a particular functionality of a software is measured against a set criteria. There may be many reasons why there is not that much emphasis in writing them, especially in small projects, but we will mention 2 most frequent ones.

  1. It just takes too much time

It may seem that writing tests takes too much time rather than simply jumping directly into the implementation part, especially if you are applying test driven development (TDD). This is true in the short term, but if we take into consideration the time you may potentially need to fix all the bugs which may likely be avoided by writing tests, then writing tests can actually save up time and even money along the way.

Project managers who have not a programming related background and that are not that much informed about the programming complexities that may arise all of a sudden tend to have high expectations from developers on their teams. They want to have quick implementations, and fast production-ready code, and simply consider it unreasonable to postpone a strict deadline.

Although these cases may put you into tough situations between following best practices or going through the fast-and-dirty schema, you should try to have some professional principles you stick to no matter what. You should try you best to convince your manager about the importance of good practices and how they pay off in the long run. If he is not convinced, then you may consider to change your workplace whenever you can.

  1. The fear of writing tests

It is no surprise that software developers spend most of their working hours either reading, writing, or discussing about solving problems through their code. As a result they have a very strong emotional attachment to it, and prefer to treat it as their precious property.

They are confident that they are already experienced enough and that they are capable of covering every possible scenario without much effort. They usually may have an inner insecurity, however, that bothers them to write tests. They have quickly pushed their code changes to the master branch because they wanted to look as productive employee in front of their manager by finishing off a task fast, and now fear that writing tests may actually reveal bugs in their code. They are afraid of being exposed as average programmers that cannot write bug-free code.

You should not let that type of ego command you into the abandonment of writing tests. You may feel uncomfortable, not smart, and all those mixed-up feelings of fear of humiliation, but in the end, you should take responsibility for your own work. It is the only way to avoid countless bugs that may take lives of millions of people out there.

You should have the courage to overcome your fear of writing tests, and change the emotions you associate to them. You should be enthusiastic and energized, simply because you are following some of the best practices of software development and helping your team build programs that have considerably less bugs.

Make time for testing

There may be projects out there for which it may not be necessary to have tests, but in most cases tests are more than welcome.

Don’t take me wrong: There are a lot of developers out there that write tests and carefully analyze and make sure they cover each edge case. The purpose of this article is to raise the awareness and invite more developers to write tests as well. Moreover, I hope it serves as an eye-opening to project managers out there as well that are constantly neglecting the need to postpone a humanly impossible to reach deadline in code implementations.

Although writing tests may not be the ultimate way to avoid the appearance of every software bugs, it is still a very powerful way to increase the chances of having more stable software projects.