Now large companies pay more and more attention to unit testing of projects, and even explicitly require that the unit testing coverage of projects should not 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?
The testers are only doing business integration testing, that is, black box testing. There is no way to test a single method, and the range of bugs tested will also be very wide, and the scope of bugs cannot be determined at all. Take the time to determine where the bug is.
In addition, one of the most common questions: wasting time writing a single test? Have you calculated the time you have to fix the bug (location + fix), and if you count it, you will find that more time is wasted.
Reference suggestions
Regarding how to write unit tests, here are a few suggestions for your reference:
1. Externalization of test data
There are two types of test data: changing and unchanging. For the unchanged 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 cases 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 use parameters such as junit5 to test annotations @ParameterizedTestand introduce CVS file annotations @CsvFileSourceand specify the resources attribute to specify the CSV file. The numLinesToSkip = n attribute specifies to start at line n + 1. In this way, the data in a unit test case can be managed uniformly through a CSV file.
We only need to manage one CSV file to manage the data needed in the test cases.
The following can be seen a case: (For the specific use method, please see the blog junit5 series-parameterized test )
@ParameterizedTest@CsvFileSource(resources = "/two-column.csv", numLinesToSkip = 1)void testWithCsvFileSource(String first, int second) {
assertNotNull(first);
assertNotEquals(0, second);
}
Among them, the content of the two-column.csv file
Country, referenceSweden, 1Poland, 2"United States of America", 3
2. 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 produce specific results based on unique data.
3. The testing aspect is comprehensive, and each aspect of the design must have a test case:
All positive situations
All negative situations
Critical value
Special value
4. Please try to be concise and short
The code should be as concise as possible on the basis of completing 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 do you want to see more?
5. Test cases as fast as possible
For unit test cases, almost every time we develop a method or modify a method, we almost always run the test case again to ensure that it does not affect the normal operation of other modules, so we should try to make your test method "fast!", Remove some code that has nothing to do with unit testing. Of course, the premise is to ensure the integrity and correctness of the test. Zhengzhou Professional Infertility Hospital: http://jbk.39.net/yiyuanfengcai/tsyl_zztjyy/3032/
6. Every time you run a unit test, make sure that it is 100% successful!
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 expiration, method internal logic changes, etc.
这些可能会花费你的一些时间去修改，你往往可能不愿意，不过既然做了一件事，就做好一件事呗
但是如果你不注意这些小错误，这可能就会导致你的一个大流程失败，大家应该知道，我们在运行一个流程时往往一个小小的错误就导致流程整理失败！
7. 设计好你的测试
这包含的方面就比较广了，下面几个方面我认为大家应该注意的：
前面所说的代码在保证质量的前提下尽量简洁
单元测试中代码的抽象也是可以有的，我们也可以将一些可重用的代码抽象出来，提高代码的重用性和减少代码的重复。
给测试类测试方法起一个好名字。测试类一般是“类名+Test后缀”，可以表示对哪个类进行的测试。测试方法也是类似，“测试方法名+Test后缀”或者对一个方法的部分测试“测试方法名+测试部分作用+Test后缀”。郑州不孕不育医院哪家好：http://www.zzfkyy120.com/
每个测试方法对被测试方法的功能断言不宜过多，如果一个方法需要多个断言进行测试，我们可以进行大致分类，将其分不到两个测试方法中，这样可以细粒度的进行测试。
8. 注意测试代码覆盖率
一个设计好的单元测试，其代码测试覆盖率也是很高的，并不要求100% 的测试代码覆盖率，但是高覆盖率的代码包含未检测到的错误的几率要低，因为其更多的源代码在测试过程中被执行。
注意：高代码覆盖不能保证测试是完美的，所以要小心！
9. 还有就是一些其他的注意点了，比如
不要使用print语句去输出测试结果人工判断是否正确，要使用断言
一些不好理解的测试最好在方法上面写明注释，便于后期理解与维护
使用框架进行单元测试，比如Junit5如果其中的断言支持不满足你的需求也可以使用ASsertJ框架来丰富断言，Mockito进行Mock数据等
好了，上述就是对如何写好单元测试的一些建议，如有不当，请在评论区中指出，感激不尽！