Introduction

"No code is the best way to write secure and reliable applications."--Kelsey Hightower

Many developers have probably more or less heard of Unit Tests, and even written one and are familiar with it. However, in the volatile and fast changing environment, unit tests seem to be in an embarrassed situation. Developers know it is useful, but treat it with neglect. "The schedule is tight. What time do we have for unit tests?" Does it sound familiar?

What is Unit Test?

Unit Test is some lines of code written by developers to validate whether their own functional codes can run as expected. If the code is not passed, it means the functional codes are problematic.

This self-testing method looks self-deceiving, similar to taking an exam with official answers. In validation area, this term is called White Box Test. The counterpart of White Box Test is Black Box Test which uses other methods to validate things. Unit Test is White Box Test, and higher-level testing methods such as Integration Test, End to End Test, and UI Test are all Black Box Tests. Unit Tests only test code itself.

What are the benefits of unit testing?

Unit testing is a very useful tool in Agile Development. Some agile frameworks, such as eXtreme Programming (XP), requires that every feature must be covered by unit test cases. My previous article Talking Agile: Are you sure your team is practicing Agile properly mentioned the importance of unit tests.

Overall, unit tests have the main benefits as below:

• Sustainable Quality Assurance: Unit tests can make sure functional codes working as expected after being changed or refactored.
• Automatic Integration: Unit tests are normally integrated in CI/CD pipelines, and will be triggered once the code is committed.
• Feature Documentation: Unit test cases can help new maintainers to get familiar with features and validation criteria.

Therefore, it looks like unit tests can bring a decent amount of benefits to software development.

Why give up unit testing practice?

Unit testing can improve our product quality and test efficiency, so why so many developers are not fond of writing unit tests? According to JetBrains, only 57% of respondents write unit tests, and only 35% will integrate automatic tests in most of their projects.

So why is that? There are several possible reasons:

• More work: "I need to write 100 lines of code to test a feature with only 50. How can I get it done without overtime?"
• Self-confidence: "As a senior developer, can you imagine there are bugs in my code?"
• Not useful: "Do I really need to write unit tests for a limited number of pages?"
• Dedicated testers: "Here you have QAs. Aren't they the guys to find bugs?"

However, they are not strong enough to be correct. Firstly, the amount of codes for bug fixing is way more larger than that. Apart from that, statistically speaking, there is a chance for a highly skilled developer to make mistakes if they write enough code. Furthermore, simple modules referenced by many other ones can become too important to fail. Finally, the responsibility of QA is ensure the overall quality instead of the locality of robustness, and have you seen any high-quality products full of buggy components?

To be farsighted

In fact, the main reason for the issue is the mindset. Most of the time developers tend to think from an individual and short-term perspective, instead of considering long-term benefits. As a good developer, he or she should develop something that is of most value in a most efficient way. Therefore, the fact that unit tests cannot bring visible benefits in a short period, makes it neglected by the majority.

Unit testing is like reading books, which cannot quickly make people knowledgeable, wealthy or famous, but can be significantly effective in the long run. If unit testing becomes the corporate culture, it is much easier to deliver high-quality products and services. Promoting it requires something more: either fundamental agile processes like XP or TDD, or high-level management such as CTO or architects.