Foreword:
Now large companies are paying more and more attention to the unit testing of projects, and even clearly require that the unit test coverage of projects cannot be lower than a certain value, which shows the importance of unit testing;
Imagine if there is no unit test, then how to ensure that the code can run normally?
What the testers do is only business integration testing, which is black box testing. There is no way to test a single method. Moreover, the scope of the bugs tested will be very wide, and the scope of the bugs cannot be determined at all. Take the time to determine where the bug is.
In addition, one of the most common questions: Is it time to write a single test? Have you ever calculated the time you took to fix the bug (location + repair)? If you do this, you will find that more time is wasted.
Suggest:
Regarding how to write a good unit test, here are a few suggestions for your reference:
- Externalization of test data
Test data can be roughly divided into two types: changing and unchanging. For unchanging test data, we can write it in the unit test case code, or we can externalize the data.
When the test data is constantly changing, and the amount of test data is relatively large, you can use test data externalization to place the data outside the test case for unified management.
What is data externalization? It is to put the data in the external unified management of the unit test case. For example, we can put the test data in a unit test case in a CSV file.
We can specify the CSV file by specifying the parameter test annotation @ParameterizedTest in junit5 and the annotation @CsvFileSource in the CVS file and specifying the resources attribute in it, and specifying the numLinesToSkip = n attribute to start from line n+1. In this way, the data in a unit test case can be uniformly managed through a CSV file.
We only need to manage each CSV file to manage the data needed in the test case.
Here is a case: (For the specific usage, please see the blog junit5 series-parameterized test)
Insert a picture description here, and insert a picture description here for the
content of the two-column.csv file
- Build tests with specific results
If the method results are random, such a method is almost impossible to test, so we have no way to test this method.
We can only test methods that get specific results based on unique data.
- The testing aspect is comprehensive, and there must be a test case for each aspect of the design:
Positive All Scenarios
Negative All Scenarios
Critical Value
Special Value
4. Please try to be concise and short
Try to concise the code as much as possible on the basis of the completion of the test, which not only makes the code more beautiful, but also maintains and understands. Think about a lot of code and a few lines of code, which one would you prefer to see?
- Test cases as fast as possible
For unit test cases, almost every time we develop a method or modify a method, we will run the test case again to ensure that it does not affect the normal operation of other modules, so we should try our best to make your test method "fast!", Remove some code that has nothing to do with unit testing. Of course, the prerequisite is to ensure the completeness and correctness of the test.
- Every time you run a unit test, make sure it runs 100% successfully!
This is relatively simple, but it is more difficult to do, because there may be a variety of reasons that cause your test case to fail, such as: data expired, method internal logic changes, etc.
These may take some of your time to modify, and you may often be unwilling, but since you have done one thing, do one thing well.
But if you don't pay attention to these small errors, this may cause a large process of yours to fail. You should know that when we run a process, a small error often causes the process to fail!
- Design your test
This includes a wider range of aspects. I think everyone should pay attention to the following aspects:
The code mentioned above is as concise as possible under the premise of ensuring quality.
The abstraction of the code in the unit test is also possible. We can also abstract some reusable codes to improve code reusability and reduce code duplication.
Give the test method a good name. The test class is generally "class name + Test suffix", which can indicate which class is tested. The test method is similar, "test method name + Test suffix" or "test method name + test part effect + Test suffix" for part of a method test.
Each test method should not have too many functional assertions for the method being tested. If a method requires multiple assertions for testing, we can roughly classify it and divide it into less than two test methods, so that fine-grained testing can be performed.
8. Pay attention to test code coverage
A well-designed unit test has a very high code test coverage. It does not require 100% test code coverage, but the high-coverage code has a lower probability of undetected errors because it has more The source code is executed during the test.
Note: High code coverage does not guarantee that the test is perfect, so be careful!
- There are some other points of attention, such as
Do not use the print statement to output the test results to manually judge whether the test results are correct. To use assertions for
some tests that are not well understood, it is best to write comments on the methods to facilitate later understanding and maintenance.
Use the framework for unit testing, such as Junit5 if the assertions are not supported. To meet your needs, you can also use the ASsertJ framework to enrich the assertions. Mockito has completed mock data and
so on. The above are some suggestions on how to write a good unit test. If there is any inappropriateness, please point it out in the comment area. Thank you!
Written at the end:
Although you’re tired when you’re busy, you’ll feel particularly refreshed and comfortable when you’re busy; when you’re free, you’ll get flustered when you’re free. There is often only one reason why you are confused, and that is, at an age when you should work hard, thinking too much and doing too little.
So friends set the goal, don't forget the original aspiration, go forward courageously, and believe that in the end, you will be able to bloom a flower of your own. Come on.