“The best way to develop a safe and reliable application is to not write code.” –Kelsey Hightower

Many developers should have heard of Unit Tests to a greater or lesser extent, or even written them, or perhaps knew something about them. However, in today’s rapidly changing environment, unit testing seems to be becoming a chicken rib. Programmers know its benefits, but seem lukewarm. “With so much time to go, what time do you have to write unit tests?” Does that sound familiar?

The so-called unit test, in short, is that the programmer writes test code to verify that the functional code they write can run as required. If the test code does not pass, it means that the functional code you wrote is problematic.

This way of testing yourself seems ridiculous, and it is equivalent to looking at the answers during the exam. However, in the field of testing, there is a technical term for such a method called “white box testing”. The opposite term for white-box testing is called “black-box testing”, which means to verify it in other ways. Unit tests are white-box tests, while more advanced tests such as Integration Tests, End to End Tests, and UI Tests are black-box tests. “Unit tests are simply testing the code itself.”

Unit testing is a very useful tool in Agile Development. Even some agile frameworks, such as Extreme Programming (XP), require that every feature be covered by unit tests. In the previous article “On Agile: Is Your Team Practicing Agile Correctly?” The importance of unit testing was mentioned.

In summary, unit tests have the following important roles:

So, on the surface, unit testing brings relatively large benefits to software development.

Unit testing can improve the quality of our products and test efficiency, so why do programmers still not like to write unit tests? According to JetBrains, only 57% of respondents write unit tests, and only 35% implement automated tests in most projects.

So, why? There are several possible main reasons:

However, these reasons do not stand up to scrutiny: First, in the long run, the amount of code written to fix the bug is certainly much more than that; Second, no matter how good the programmer is, the code is written too much, according to the big number theorem, there will be mistakes; Third, simple features can also become important if they are referenced more; Fourth, the main job of QA is to ensure the overall quality, while unit testing is to ensure local quality, will the product assembled by the defective parts be of high quality?

In fact, the main reason here is the “thinking mode”, programmers will most of the time from the perspective of the individual, thinking about short-term problems, thus ignoring the long-term cost benefits. As a qualified developer, the primary goal is to develop the most valuable features in the most efficient way. As a result, unit testing fails to create value in a short period of time and is overlooked by many people.

Unit testing is like reading a book, which cannot make people knowledgeable and famous in the short term, but it will be effective in the long run. Unit testing becomes a habit or organizational culture that makes it easier to build high-quality products and continuous delivery. Promoting unit testing in your team requires more fundamental processes, such as extreme programming, test-driven programming, or higher decision makers, such as CTOs, architects.

If you are interested in the author’s article, you can add the author WeChat tikazyq1 and indicate “the way of the code”, the author will pull you into the “way of the code” exchange group.

The English version of this article was published simultaneously on dev.to[1], technology sharing without borders, welcome the guidance of the big guys.

dev.to: https://dev.to/tikazyq/talking-testing-the-love-and-hate-of-unit-tests-5gl