Why you shouldn’t skip unit testing for building high-quality software

If you’re a developer or work in the world of software development, you might have heard some misconceptions about unit testing. We’ll go debunking some of them one by one in this post, and maybe you’ll see unit testing in a new light.

Common Misconceptions About Unit Tests

“Unit testing is useless.”

This is probably one of the most popular misconceptions around unit testing in the dev world, but it’s far from the truth!

Unit testing offers several benefits for a project. To start with, it helps to detect issues at an early stage of the development process preventing several costs in the future without affecting any other parts of the software. It also gives us the opportunity to make the code more robust. Moreover, detecting and fixing bugs is much easier when found in a unit rather than in the whole system.

“Unit testing slows down development.”

Even though unit testing may seem like it makes the development process slower, it actually does the opposite: if you invest time in unit testing now, you will save much more time tomorrow, which means you save time!

“The code is so simple, why should I write a test for it?”

Not only does unit testing prevent bugs in code, it also makes it more reliable and stable. It promotes better architecture, design, and maintainability. You will definitely sleep better if you know your code is undergoing unit testing!

“Testers are in charge of unit testing.”

Actually, this one is also a great distance from the truth. Following the shift-left methodology you could misunderstand “do more testing early in the project” as “let the testers do their stuff early”. Testing is not only the responsibility of testers. There are many testing tasks that could and should be performed by programmers. Unit testing should be part of the development process and developers have to take responsibility of their own code by “assuring” that it’s working as expected. This way, testers can work on more complex test cases with a high level perspective, testing business flows. Also, they could also have more time to test other aspects of the system like its performance, security, accessibility, etc.

“We have integration tests, so we don’t need unit tests.”

We tend to believe that if we test the system as a whole, we are testing the units as well. In fact, this is not true. Jerry Weinberg claims the idea that testing a whole system will simultaneously test its constituent parts is a fallacy of decomposition. What happens if you want to use one of your units (which are supposedly tested) in a very different scenario? What should you think about your code’s reliability if it doesn’t work in other environment? These are questions you can answer via unit tests.

In some cases, it’s difficult to mock the classes or services that a unit uses, and if so, it’s ok to test everything together, but at least try to apply white box testing techniques.

Final Thoughts

It’s important to note that unit testing (as with any type of testing) is optional, not a requirement. When you are developing a product, it’s up to you to decide whether you want it to be of a certain standard of quality or not. If you are concerned about quality, you should start by verifying and improving your software’s units and components.

Think about testing when you want to create a robust, secure, efficient, and stable system that users will love. Making sure that the quality of your products is high is an ongoing process that evolves over time. The amount of effort you put into it tells a lot about your engagement with clients and the responsibility you take for offering high caliber products. Unit testing is just a small piece of the journey. Nonetheless, the tremendous benefits it offers are too good not to consider!

Recommended for You

The True ROI of Test Automation
Best Testing Practices for Agile Teams: The Test Automation Pyramid