Why do you need unit testing?
From a product perspective, conventional functional testing and system testing are based on testing local or global functions of the product, which can be well integrated with user needs, but lack understanding of product development details (especially code details) ).
From a tester's perspective, functional testing, system testing and other performance testing require a higher level of understanding of global features. As long as testers can master one or two automated testing frameworks, they can basically carry out automated testing of functions and performance. However, using the testing framework for research and development reduces the requirements for testers to master and understand the code.
From a developer's perspective, user needs are often not specific and comprehensive. Therefore, there are often limitations in converting development documents based on user needs or writing development code for a certain function (that is, what we often call bugs). .
Therefore, writing unit tests can help testers better understand code details and improve code development capabilities. It can also help developers identify possible bugs in the code in advance and improve the fault tolerance of the code.
How to create a unit test report
A good unit test report can help testers better analyze and discover potential problems. So, how to formulate a unit test report and from what dimensions? Here we mainly think about this issue from the perspective of testers.
First, we need the report to be able to present the number of our test cases and test results (pass or fail), as well as error details.
Secondly, based on the characteristics of unit testing itself, we need the report to be able to show the coverage of unit code branches, unit methods, etc., to better help us sort out and test the excellence of test case design.
Here, we use surefire-report to count the number of test cases and test results, and use jacoco to count unit test coverage (Note: The default execution method of test cases in this article is mvn test).
1. How to configure surefire-report and jacoco ·surefire-report configuration
Configuration method: Configure the maven-surefire-plugin plug-in. maven-surefire-plugin is maven’s default test
Executor, the configuration method is shown in the figure below:
In the above figure, testFailureIgnore means to ignore errors in unit tests and continue building. <include>**/*Test.java</include>: means all Java classes named ending with Test in any subdirectory, <exclude> **/Test *.java </exclude>: Indicates that all Java classes named starting with Test in any subdirectory will not be executed.
Execution method: Use mvn test surefire-report:report, which will be generated in
/target/site/surefire-report.html Test report document. As shown in the figure below: Tests displays the total number of use cases; Errors refers to situations that the program has not considered, such as exceptions that cannot be caught; Failure refers to the difference between the expected results and the results of the actual running unit, often appearing at assertions ;Skipped represents the number of skipped test cases; Success Rate represents the success rate of use cases (=number of successful use cases/total number of use cases); Time displays the total time taken. Package List displays detailed use case execution results under the package.
·jacoco configuration
Configuration method: Configure the jacoco-maven-plugin plug-in. The configuration method is as shown in the figure below. Phase represents the life cycle stage in which the plug-in runs.
Execution method: Just execute mvn test. The total coverage report index.html and the unit test coverage report of different packages will be generated in the /target/site/jacoco/ directory../xxx/index.html. There are also unit test coverage reports in csv and xml formats.
The figure above shows the unit test coverage report of a certain package. The red progress bar indicates that it is not covered, the green progress bar indicates that it is covered, and Cov is the overall coverage rate. Missed Instructions represents code coverage, Missed Branches represents logical branch coverage, Missed Cxty represents the number of judgment executions, missed Lines represents the number of lines of code, and Methods represents the number of methods.
Finally, I would like to thank everyone who reads my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, if you can use it, you can take it directly:
This information should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can also help you!