Basic concepts (UT) that need to be understood before conducting Unit Tests)

The purpose of this article is to help you clarify some concepts before the formal unit test. What isUnit Test, What can be done, and what guiding principles are there. What are the advantages and limitations of the solution. Finally, the difficulties in unit testing are highlighted. In fact, this is a problem that any unit test will face. I would like to share my point of view with you!
1. What is UT?
UT tests the method and tests the commitment of a class to the outside world. Therefore, in most cases, we should test public methods unless we have to test private methods. The method is the minimum unit of program design. The limitations of UT are also reflected here. It does not validate the interaction between classes. Therefore, you cannot expect that the unit test is complete, so there is no problem. In this regard, we can do this through automated function/component testing. This is also part of the developer test.
Ii. UT tasks
1. If you discover the problem as soon as possible, do not let the problem flow out. This will reduce the defect rate and make our products beautiful. On the other hand, it is easier to find out some issues with the level of detail here, as well as preparing for integration for testing with greater granularity.
2. woven a protection network
Create effective protection for new code. Make sure that every change to the code will not cause harm to the existing system. This avoids the introduction problem.
3. Write elegant code
The process of writing unit tests is actually the process of using our own code. We became the first real experiencer. In this process, we will constantly refactor the Code to make it easy to use. The final delivery code will inevitably become more elegant.
4. build the confidence of programmers
We are used to writing the code in November, regardless of whether the code is completely written. The Code stage is over, and then the debugging is continuously completed. The TR4 process is completed after the repair and completion. No one dared to say that he could run as soon as he finished writing the code. This approach is very unhuman. After the system has been engaged for several times, it becomes a weakness in your mind, with no confidence at all. However, this is our profession, and we fight for our own glory. At any time, confidence is needed.
III. Basic UT principles
1. One class, one method, and one path. We test only one method of one class at a time. At the beginning of the unit test, many people naturally made functional tests. Because the results of the execution in the previous part happen to be the input in the later part. On the other hand, the continuous execution process forms a clear scenario to make specific functions complete and visible. This is what we expect and gives us confidence. Why not let it go?
The reason is:
1) unit testing should ensure a certain level of granularity. From unit testing to functional testing, the granularity is getting bigger and bigger, and we will pay less attention to details later. If you directly jumpFunction TestingIn this case, we will omit some issues. In the future coarse-grained tests, they will turn into critical problems that are hard to reproduce or cannot be reproduced.
2) the reason for the above scenario is that the Code is first written and then tested. This is equivalent to the fact that the Code has been integrated and has certain functional testing conditions. At this time, let's go back and perform unit tests. Of course, it's better to directly perform functional tests. Therefore, one test, one method, one method, and one test should be performed, so that it is better to integrate loop iteration step by step.
On the other hand, to separate multiple execution paths of a method, we must ensure that only one path of one method is tested at a time. In this way, the pre-and post-conditions are clearly defined and the test environment is easy to prepare.
2. Refactoring for testing
You feel helpless in the face of a method. It's not your fault, but it's a bad method. One way to test this is to use this method. You are helpless yourself. Isn't it necessary for someone to call this method in the future? When the wild geese pass by, people pass by their names. At this time, refactoring is worthwhile.
3. Make sure that the test method is simple.
If the test method is complex, do we have to write more?Test CasesTo ensure that it is correctly executed? This is not a big headache! Therefore, the test method must be as simple as possible, to the extent that you think the idiot can understand.
4. How to do UT
1. The code must be measurable before testing. First, we must abide by the contractual design. Each method of the class should assume a contract with clear preconditions and preconditions. Before testing this method, you must understand these two conditions. An effective method must have done something. It will definitely have a certain impact. We can check whether the function of the method is as expected by changing the peripheral environment (for example, obtaining the attributes of an object for detection ).
Second, low Ce and single responsibility principles. The external dependency of a method should be single and should not depend on many external environments. Because the more external environments, the more combined items, the more prerequisites for testing. A method has too much influence on the external environment, which means that the responsibility is not uniform and the output is harder to test.
I have heard of people who once said that these principles are useless if you understand them. However, I think that unit testing is a good way if you think this is just a truth.
2. Trust your trust.
For a stable part, similar to a third-party package or platform part, it is a proven reliable part of the legacy system and can be trusted. These are the dependent parts of our use case code, and are the cornerstone for us to test other parts to be tested. If everything needs to be tested, nothing can be tested.
3. unit testing should minimize the burden on developers.
On the one hand, we have been put down by the problem list for too long. Therefore, looking at this problem from the global perspective, if we can indeed reduce the maintenance pressure in the future, it is of course beneficial to ourselves. The increasing burden is just getting rid of some pain points.
On the other hand, unit testing must be automated, simple, and foolish. This is our goal.
4. Use the debugging time to writeUnit Test
Those who have not completed automated unit tests will never be able to understand the self-confidence and benefits they bring to programmers. If you are still debugging, it is better to add a test. In the future, make sure that the same problem will not slip away from your eyes.
5. What are the difficulties in unit testing?
Difficult to pile up. Because our association with other modules is like this.
This is troublesome, and there are too many associations. If we want to test, we need to pile up.
1. daunting, too many.
2. It cannot be started. It is a direct object dependency instead of an interface dependency.
So I won't do it if you let me test such code.
Because what I want is:
However, our current code is in debt too much. There are no conditions and capabilities to go back and perform unit tests on the code. Moreover, after so many years of maintenance, these functions are mostly stable. The cost-effectiveness is not high, and it is not affordable. Therefore, you do not have to do this.
But in the process of developing new functions, these old code will still be entangled in us like a nightmare. This makes it difficult to write unit tests. We have to choose between making the code measurable and testing the code.