Unit testing is very important, but it is difficult to do well. According to the projects I have experienced, there is basically no way to do it well. Unit tests for many projects are either useless or not at all.
Recently, I was studying the source code of Mybatis, and I saw the single test case of Mybatis, which was done very well. Here, combined with the projects I have experienced, I will summarize the two most important points of unit testing:
1. Don't depend on the environment
Unit testing requires some environmental initialization during initialization to ensure that the use case can be executed repeatedly next time, without any environmental dependencies, otherwise it will be meaningless.
See how Mybatis does it:
All Mybatis test-dependent resources are placed in the same package as the test case; when it comes to database-related operations, an in-memory database is started in the beforeClass method of junit at the beginning of the use case, and all operations are based on in-memory database operations , to ensure that there are no dependencies with the environment.
This is necessary in unit testing. In fact, in all automated tests, we must find a way to eliminate the dependency of the environment. Let's take a look at the counter example:
This is also a unit test, which is mixed with various information such as domain name, IP, port, etc. It can be said with certainty that this use case is likely to fail in less than a week. This problem exists in many projects. Due to various reasons such as project duration, it is easy for developers to make this mistake when writing test cases.
How to avoid hard coding like this kind of domain name, IP, port?
My solution is to automatically start Docker in the code at the beginning of the use case, and assign IP, port, domain name and other information to Docker, and the test case directly accesses the started Docker service instead of the real domain name, URL and other information online . Destroy Docker after use case execution is complete.
In this way, the test cases only depend on the underlying Docker services, rather than various hard-coded environment data. Repeated execution of test cases can be guaranteed.
2. Each use case requires a recovery environment
There may be multiple use cases in a test class, and each use case will make some adjustments to the test environment, so there may be influences between use cases.
This effect is sometimes difficult to detect, and once it affects the test results, it may not be tested, but this does not mean that the function is faulty.
Therefore, in each use case, the impact on the environment must be handled by itself, such as changed parameters and opened connection pools:
This awareness is important during the actual test case writing process.
For example, when testing the update method, the value of the field is changed from A to B. When many people write test cases, it ends when the verification value becomes B, and B will not be restored to A. If there are other use cases that depend on the value of the field, the test will fail.
When there are many test cases, it is hoped that the test case can be run through again and again. If it fails, it needs to spend a lot of energy to analyze why the abnormality occurs, which will cause low efficiency. And it is easy to cause developers' distrust of test scripts and rejection of test cases, which is the most fatal.
One thing, either don't do it, or do it well. Otherwise it will always be half-tone.