First, the words written in the front

As a programming practitioner, unit testing is no longer an obscure, unknown, and neglected concept. But at the same time, in practice, unit testing is poorly practiced in real project development, except that open source SDKS generally come with unit testing as standard. There are many, many reasons for not writing unit tests. The most common reason I hear for not writing unit tests is, “Don’t have the time, but don’t have the time” equals “optional”. Can I equal unimportant? That is, given enough time, can unit tests be implemented? You get 100% coverage? The author will elaborate his own understanding on these issues later:

2. Is unit testing necessary regardless of time?

Imagine a scenario where you write a function that computes the amount when you pay. It involves counting discounts and zeros. At this point in the normal logic you have run without error, but the real scene is more complex, then their simple function verification (or not verification) directly to the tester for acceptance. At this point, based on the following two situations plus no unit test:

(1) Testers are just another layer of software security, not the only one; (2), the vast majority of the tester are a stop at the ‘little’ level (don’t mean to belittle the tester, but current situation is indeed)

There’s a very high probability that the software we end up with will be compromised. Suppose that after the launch, the actual amount calculation bug occurs, leading to operation and maintenance accidents or even customer complaints. At this time, assuming that the company has assigned 100% of the responsibility to the testers, the author will not comment more. Most of the time, as long as the company is sensible, the writer himself is largely responsible.

For example, if the food out of food safety accident, at this time quality supervision department has responsibility, but food processing plants have more responsibility.

That is to say, due to our own technical work literacy, we should have enough control over the quality of the software, not relying on the testers to find problems, let alone rely on the launch of the lucky no problems. Now imagine this scenario: you tell the leader, I can do it in two days, but I can do it in three days with maximum quality and quantity. I believe that as long as some product awareness of the leadership, I believe are willing to wait for that day. Or, if not, wait to go online and try it out? At this point, unit testing is a great tool for developers.

What is the real resistance to unit testing practices once the necessity is clear?

Can you really write unit tests well given the time they say you don’t have? Can the coverage reach 100%? According to the answers I heard from my friends in the same industry, as well as the answers from job applicants, they are basically negative. In other words, in the author’s understanding: no time = excuses or writing unit test functions, as well as the function under test, is technically difficult. Here I would like to share a key concept:

Measurable function

I’ve heard a lot of questions from friends who want to try to write unit tests that they can read and write the official Demo because it is so simple (such as adding and subtracting). However, when I went back to my own project, I found that I had no way to start, such as the following Demo

Const SDK = require(" tripartite dependency "); Const db = require(" database connection or Model"); Const otherServices=require(" other function or business file "); module.exports = function(){ //do sth. return; }Copy the code

At this point, if you want to test this function, you will find that the unit test script will immediately report an error as soon as it introduces the file under test. On the one hand, the database connection information error, on the other hand, unknown other business JS introduction error. In other words, this function cannot be tested because there are too many external dependencies

Dependency inversion/dependency inversion

Baidu Baike: In the object-oriented programming world, Dependency Inversion principle (DIP) refers to a specific form of decoupling (traditional dependencies are created at a high level, while specific policy Settings are applied at a low level), By making the high-level modules independent of the low-level modules’ implementation details, the dependencies are reversed (reversed), thus making the low-level modules dependent on the high-level modules’ requirements abstraction.

For example, the following simple Demo program

Const SuccessBusiness=require(" callback handler "); Const ErrorBusiness=require(" failed callback processing "); Module.exports = function(){// ★ SuccessBusiness(); module. Exports = function(){// ★ SuccessBusiness(); / / or ErrorBusiness (); return; }Copy the code

That is to say, the core logic to be tested for the above Demo program is part of the logic, but it has to introduce two dependency functions unrelated to the main logic, and the function of the two dependency functions in this function is only: Positive dependencies are triggered at the right point in time, so the test case can’t move forward and can only be changed through dependency inversion. This is not too advanced a theory, you must have seen it in daily development, such as the following Demo:

Module. exports = function({onSuccess,onError}}){// ★ exports = function({onSuccess,onError}}){// ★ exports = function({onSuccess,onError}}){// ★ exports = function({onSuccess,onError}}){// ★ exports = function({onSuccess,onError}}){// onSuccess(); / / or onError (); return; }Copy the code

At this point, this is a very popular functional form for test cases.

  • Verify the main logic of part ★ by passing in different arguments
  • The onSuccess and onError functions in the Mock entry parameter
  • Verify the success of the Mock functions by determining how many times they are executed.

In other words, the success of unit testing may be more about demanding high standards for original master logic coding.

Four, two last words

In fact, it is too narrow to say that unit testing is for error-free purposes. There are many more far-reaching meanings of unit testing, such as requirements completion: does the code level cover all requirements refactoring? It’s common to see “refactoring problems while optimizing code”, but with unit tests, refactoring is a boon. Developers can make changes as long as the original N unit tests still work.

Otherwise it is always a trial, and no one knows where he has touched by mistake. Here I also recommend some TDD test-driven development, interested friends can learn by themselves.

Finally, I would like to reiterate the importance of code testing for developers. If developers do not have hard and fast assurance of the quality of their output, but rely on feelings and experience, it is not qualified. As for the testing work for the RESEARCH and development, what can be done, the author will continue to share, such as small and medium-sized testing, automated testing, stress testing and other concepts. Comments, questions and corrections are welcome! 😊 😊 😊 😊 😊