How do I improve development efficiency through unit testing?

Kevlin Hnney, an independent consultant and trainer in the UK, focuses on software architecture, patterns, development processes, and programming languages. In this article he will talk about how to improve development efficiency through unit testing.

Is unit testing just a waste of time? That's what some software experts really think. Recently saw an article in software Quality Insights--"unit test really useful?" 》。 Developers who think unit testing is useless give the following reasons:

1. They do not understand unit tests.

2. It is difficult to write excellent unit tests.

3. Unit testing can only waste time and reduce efficiency.

4. It takes too much time (especially frequent iterative development) to write unit tests.

5. Regression testing is more efficient.

This article will focus on the next three questions, that is, the relationship between unit testing and development efficiency.

Efficiency vs personnel arrangement

Does unit testing reduce efficiency and lead to wasted time? It depends on what efficiency is described and who the time object is. In a cycle of purely new code writing, programmers who write unit tests may write less code than do not write unit tests. If the efficiency is said to be this, then unit testing does reduce the programmer's efficiency.

But it's easy to see the problem with this far-fetched definition of efficiency. The line of code is not a measure of efficiency, it's just the number of lines of code that is written. From a single class to the entire system, we can see that many lines of code are far beyond what is actually needed.

What we need is not more code, but accurate code. Unit tests allow us to check the authenticity of the code level at any time, and it can tell us if we're developing the right things. So the more testing it means the less code. This is no bad thing. The difference between the development rate (development velocity) and the development speed (development speed) lies in the direction. Move in the right direction even if a few steps are better than running in the wrong direction.

Another bad idea is that developers are writing new code most of the time. While developers want to focus on the code, the reality is not. Meetings (with teams, managers, customers, investors, etc.), mail, program debugging, sessions, document making, installation, research and evaluation, help with problem solving, follow-up support, merging versions, handling configuration management systems, and so on are all matters to consider.

Although the percentages vary according to the project and the company, these are code-independent activities and take up more time than the code takes. The problem is that if we use part of the coding time for unit testing, how much of that time can be translated into coded time?

Local Optimization vs global optimization

It's also important to see the whole picture. Following Alfred Aho's story about the development of the awk language, there are some things that we should consider:

"If there is another chance, we will definitely add rigorous testing when developing the language," he said. We were developing awk as a "temporary (throw-away)" Language, so we didn't consider strict quality control ... There was a man who wrote a CAD system in awk. He came to me and wanted to tell me a bug in the awk compiler. He was angry and said that I had wasted his three weeks of life because he had spent three weeks looking up the bugs in his code and found out it was a compiler problem! Then Brian Kernighan and I discussed the problem and we thought we should do some quality control work. Then we did a rigorous regression test for all of Awk's features. Since then, the three of us have written a corresponding test, no matter who adds new features to the language. ”

The point of this story is that it is an early example of a "test-first" programming approach-writing tests before implementing a feature, rather than just planning or speaking. In addition, this story shows how to turn short-term, temporary or targeted code into a long-term, stable solution.