In last week’s post, I covered several ways to improve code quality. Some readers are interested in unit tests. Today, we will talk about: Is it necessary to write unit tests? With a test team, is it a waste of development time to write unit tests?
1. What exactly does unit testing test?
For those of you who are unfamiliar with unit testing, before we get into this topic, let me give you a quick overview of what unit testing is.
Unit tests, as the name suggests, test a small “unit,” which is typically a class or method, not a module or system. Unit testing is typically done by development engineers and is code-level testing that tests the correctness of the code “you” write. Unit testing is not test-driven development. Test-driven development (TDD) is a development idea that is ideal but not practical. Unit testing is the same as test-driven development, but easier to implement. Unit tests do not rely on any uncontrollable components. If your code relies on other uncontrollable components, such as complex external systems, complex modules or classes, you need to mock them out of control.
In fact, writing unit tests is not a technical feat in itself, but rather a test of the engineer’s thoughtfulness in designing test cases that cover a wide range of normal and abnormal scenarios to ensure that the code works in any expected or unexpected circumstances.
2. What are the benefits of writing unit tests?
From my own experience, when we write programs, we tend to focus on whether the program will perform as expected under normal conditions, and we tend to think less fully about how the program will perform under abnormal conditions.
After you write a feature code, how do you make sure it works correctly? In all kinds of exceptions (data exception, input exception, call exception, etc.), the program results are in accordance with your pre-designed expectations, return the appropriate error?
This is where unit testing comes in. From my personal experience in writing unit tests, I find a lot of inadequacies and “bugs” almost every time I write unit tests. Well-designed unit test cases are very helpful in cleaning out low-level bugs in your code. So I’ve always felt that the most effective way to improve code quality is to write good unit tests. There are many projects at Google that have no test team at all. The correctness of the code is completely guaranteed by the development team, and there are very few bugs online.
Moreover, the process of writing unit tests is itself a self-code review process. In this process, you can find some design problems, such as untestable code design, code readability is not good, etc.
Writing unit tests also gives you confidence in your code. By the time you’ve written a complete unit test and your code has passed all the test cases, you’ll have a lot more confidence in your code. It’s nice to feel under control 🙂 if you’ve written unit tests properly, you can relate to me on this point.
In addition, unit tests can be very helpful in refactoring code. What do you do when you find that a class or function doesn’t work well and you want to refactor it, but you’re afraid that you didn’t think everything through and it might make a mistake?
It would be different if there were unit tests. After the code is refactored, you run the original unit test. If all the unit tests pass, it’s pretty much guaranteed that your refactoring didn’t break correctness. However, this assumes that previously written unit tests are of good quality and have high coverage.
3. Why do few companies write unit tests?
As far as I know, few Domestic Internet companies, including BAT, write unit tests seriously, especially some project teams that develop business systems. Personally, I think this has something to do with the technology culture and research and development mode of the whole company.
The technical culture of many companies, from top to bottom, has no sense of “code quality”. As long as the code compiles and works as expected under normal circumstances, it is submitted directly, and then thrown out to the test team for intensive testing. When the test team detects problems, they feed back to the development team to fix them. Problems that can’t be measured are left on the line and solved when problems arise.
In addition, many of our companies are 996, 995, business driven, schedule is tight. R&d engineers simply don’t have the time or energy to write unit tests. This is because, in general, the amount of code in a unit test is usually one or two times greater than the amount of code under test.
In this development model and technology culture, teams often feel that unit testing is unnecessary and a waste of time. However, if we, the development team, write good unit tests, do a good code review, and pay attention to the quality of the code, it is actually a long-term investment in the project.
As the saying goes, “Slow is fast.” Although writing unit tests and code review may temporarily affect the current development progress, in the long run, the overall development efficiency of projects with high code quality will be much higher.
The last
Today, I’m going to tell you about unit testing and what it’s good for. You can also leave me a comment on what else you’d like to hear about unit testing. Or what do you think about unit testing? Do you write unit tests in your projects? Do you think it’s worth the time to write?
Zheng Wang, a former Google engineer, is the author of “The Beauty of Data Structures and Algorithms” and “The Beauty of Design Patterns”. Wechat official account: Xiao Zhengge, follow wechat official account reply PDF, get 100+ pages of Google engineers’ algorithm learning and interview experience sharing.