In this section, we will learn how to use JUint to implement a logical coverage test for a program. In this course, we will learn about the logic coverage test strategies, the strength and weakness of these logic coverage test strategies, and write test scripts according to the logic coverage test strategy to complete the unit test.
First let’s take a look at JUnit.
JUnit is an open source Java unit testing framework that is an instance of the Unit testing framework architecture xUnit. JUnit provides apis that allow you to write reusable unit test scripts with clear test results.
The current release of JUnit is 4.12, and the next generation is JUnit5. JUnit5 requires Java8 at runtime, but it is still designed so that it can test code compiled using previous JDK versions.
JUnit was developed in 1997 by Erich Gamma and Kent Beck. Erich G Amma is one of the Four people who wrote Design Patterns at GOF (Gang of Four); Kent Beck made important contributions to extreme programming (XP).
“Small as a sparrow is, it has all the five organs.” JUnit is designed to be very small, but it is very powerful. As an open source project, JUnit is hosted on GitHub.
Next, let’s look at the program to be tested:
This Java program is a getNmb method, it takes two int arguments x and y, and has a return value of int. This program is not complicated. The main logic consists of two if-else statements, involving five statement blocks and two branches.
Next, we will use JUint to implement a logical coverage test of the program.
Specific coverage strategies include statement coverage, judgment coverage, condition coverage, judgment – condition coverage, combination of conditions coverage and path coverage.
Next, we first analyze the process of this procedure.
This is the flow chart we drew after analysis.
From the flow chart, we can see intuitively that there are two judgment boxes and five statement blocks. Where A, B, C, D, E and F are several program points on the control flow.
Let’s first design test cases for statement coverage:
Statement coverage means that during testing, several test cases are first designed, and then the program under test is run so that each executable statement in the program is executed at least once.
Based on this test strategy, we designed two test cases. They cover 1, 3, 5 and 2, 4, 5 respectively. We have a total of five executable statements in our program.
Take a look at the animation:
Test case 1 takes the ABDF path, covering statement blocks 1, 3, and 5. Test case 2 follows the ACEF path, covering statement blocks 2, 4, and 5. Therefore, the test strategy of statement coverage is satisfied. Each executable statement is executed at least once.
Next we design test cases to determine coverage:
Decision coverage refers to the design of several test cases and the running of the tested program so that each true-taking branch and false branch in the program experience at least once, that is, the true and false values judged have been satisfied.
There are two if-else statements in the program under test, and each if-else statement has two decision branches, which are true, false, true, and false respectively. Ideally, the combination of “1 true 2 false” and “1 false 2 true” can satisfy the decision coverage only by designing two test cases.
In fact, we designed the test cases CASE3 and CASE4 based on this analysis.
Take a look at the animation:
The branching result of test case 3 is “true false”, and the branching result of test case 4 is “false true”.
At the same time, we also found that these two groups of test cases not only satisfied the decision coverage but also achieved the statement coverage. All five statements are overwritten. This shows that decision coverage is stronger than statement coverage, this conclusion is valid.
After decision and statement coverage, let’s look at conditional coverage.
Condition coverage refers to the design of several test cases and the execution of test procedures so that the possible values of each condition in each judgment are satisfied at least once. The first thing to clarify is that “conditions” are not the same as “judgments”! The “decision” is obvious on the flow chart, which is a diamond shaped decision box leading to a fork.
Decision coverage is concerned with the fact that when each decision branch “comes out”, whether it takes true value or false value must be covered; But condition covering pays more attention to the content and combination of conditions. A decision may contain more than one judgment condition, sometimes one condition constitutes a decision.
The second decision z> 10&&y >0 in the program under test is the combination of two conditions, which need to be removed and overwritten in sequence in conditional coverage.
So we designed three test cases.
From the design of test cases, TTT, FFT and FTF do meet the requirement of conditional coverage. But we wonder, which is better than conditional coverage versus statement coverage and decision coverage?
Let’s first look at the animation effect of conditional overlay:
The path of CASE5 is ABDF, and the path of CASE6 and CASE7 is ACEF.
Conditional coverage is usually better than decision coverage because it results in two different outcomes for each condition in a decision, whereas decision coverage does not guarantee this.
Similarly, from the perspective of “decision coverage,” your test case gets different results for each condition in the decision, but it is possible to get only true values or only false values when the decision is made. For example, there are two conditions in a decision, and the relationship between the two conditions is and. The test case is designed so that the values of the two conditions are respectively “true and false” and “false and true”, and after operation, both are false values. So sometimes, conditional coverage does not satisfy the decision coverage.
Note that:
Satisfied with conditional coverage, not necessarily can meet the decision coverage!
Conditional coverage is satisfied, and even statement coverage may not be satisfied!
Next, decider-conditional coverage:
Conditional coverage is not better than decision coverage, and they are just different in focus. Conditional coverage and decision coverage can be combined, which is called “decision conditional coverage”, which means: Design enough test cases so that each condition in a decision expression has at least one true/false value, and each decision expression itself has at least one true/false value.
So, let’s design test cases based on this coverage strategy.
On the left are the tests, on the right are the conditions, and obviously each of the true and false values of the tests occurs at least once, and each of the true and false values of the conditions occurs at least once.
Let’s take a look at the animation:
In the animation, the path of CASE10 and CASE11 overlapped, and the value of the condition in the decision was not intuitively seen during the second decision. In fact, you can revisit it in terms of computer-generated instructions.
/ conditions covering “seems to be reasonable, but it is not, because most of the computer can’t use an instruction to make decision for multiple conditions, but must in the source program decision is decomposed into several simple decision for multiple conditions, so a thorough test should make every simple decision really take to the various possible outcomes.
The figure on the right is a flow chart of the target program generated by the compilation system.
After Java is encoded into bytecode, a complex decision z>10&&y=0 is decomposed into two simple decisions Z >10 and y=0. Note the decision box in the figure on the right.
We find that when z>10 takes a false value, there is no longer any judgment on the true or false value of y>0. This may occur when the former condition is met, the latter situation has errors and not executed, not discovered. It is also a programming language && and | | “short circuit” effect, after the previous conditions on a condition of restraining effect.
Judging condition coverage from this point of view, it’s not perfect, it looks like it takes all conditions to all possible values, but it doesn’t check to that extent.
And strive to check to a more detailed degree is the combination of conditions covered.
Condition combination coverage is the design of enough test cases so that all possible combinations of conditions in each decision occur at least once. A test case that satisfies conditional combination coverage must satisfy decision coverage, conditional coverage, and decision – conditional coverage.
Four test cases were designed to achieve conditional combination coverage.
Take a look at the animation effect of conditional combination overlay.
The flow chart here is exactly the instructions generated after the source program is compiled to decompose the complex decision into a simple decision flow chart. So we can intuitively observe the more detailed coverage effect.
Finally, we’ll talk about the strongest path coverage in logical coverage tests.
Path coverage refers to designing enough test cases to cover all possible paths in the program.
We also designed four test cases.
We can take a look at the set of test cases previously designed for conditional combination coverage, decider-conditional coverage, none of which covered the entire path. Conditional combination coverage covers only abDF and ACEF paths, and determination-conditional coverage also covers only two paths.
So we’re covering it from a path point of view. The test case set here {CASE3,CASE4,CASE5,CASE6} is made up of previously designed test cases.
The effect of path coverage.
Case3-abef, CasE4-ACDF, CasE5-ABDF, and CasE6-ACEF
Now let’s go into JUnit and write a test script to test the code.
The test environment was JDK1.8, eclipse Neon4.6