There are many kinds of code coverage. Some of the types have more than one common name, plus several uncommon ones. Discussions of coverage can get hung up on name debates, with endless claims about what the right name is and what, precisely, different names mean.
As someone who`s written four coverage tools, those discussions pain me. They make the whole topic seem over-complicated. To the ordinary person, it`s really simple. There are four relevant types of coverage. They`re all easy to explain. The particular variants implemented by a particular tool have no important practical consequences and are (usually) easily understood.
I describe the four types here.
1. Line Coverage
2. Branch Coverage
3. Condition Coverage
4. Routine Entry Coverage
Line Coverage
Here`s some Java code I wrote recently (or, rather, cribbed from Wirth`s Algorithms + Data Structures = Programs):
1. private Expr orArgument() throws ParseError {
2. Expr retval = factor();
3. while (tokenType == AND) {
4. getsym();
5. retval = new ExprAnd(retval, factor());
6. }
7. tr.debugm(retval.toString());
8. return retval;
9. }
I have a test suite for the application in which this code lives. Suppose I ran that test suite. A line coverage tool could then tell me which of these lines of code had never been reached by the execution of any of my tests.
"Line 4 in file Parser.java was never executed."
(If you`re familiar with source-level debuggers, think of breakpoints. A line coverage tool essentially puts a breakpoint on every line of code. When the breakpoint is hit, it records that fact.)
It`s good to know what lines haven`t been executed. Maybe line 4 should read "factor()" instead of "getsym()". If I never execute it, I`ll never have the chance to find out. (If I do execute it, I might still not find the bug, depending on the test, but at least I have a shot at it.)
In this example, once you know that line 4 hasn`t been executed, you really don`t care to know that line 5 hasn`t been either. It`s obvious. For that reason, some line coverage tools would not tell you about line 5 in that case.
(But such a tool has to be careful not to assume too much: what if getsym() throws a ParseError? Then line 4 has been executed but line 5 has not.)
Most common programming languages aren`t defined in terms of text lines. Instead, their reference manuals talk about statements. If you`ve reached every line of code in the program, have you exercised every statement? Not quite.
Consider this code:
54: if (i < 0) i = 0;
There are two statements there: an IF statement and an assignment statement. A line coverage tool would tell you whether the IF had been reached, but I know of none that would tell you whether the assignment had. I believe that`s for the same reason that most source-level debuggers won`t let you set a breakpoint on the assignment: figuring out a workable user interface is more trouble than it`s worth.
Branch Coverage
Consider:
...
startup();
if (isFun(debating)) {
debate(); debate(); debate();
shutdown();
}
...
If the IF statement is taken false, shutdown() will never be called. That`s probably bad. A line coverage tool won`t tell you that you`ve never taken the ELSE branch because there`s no code in the ELSE branch for it to measure.
So there`s a type of coverage to help. It`s usually called "branch coverage". It checks whether all IF statements have been taken in both the THEN and ELSE directions. Ditto for WHILE statements:
while (i < 33) {
...
if (whatever) break;
...
}
post_loop_cleanup();
A branch coverage tool will tell you whether the WHILE`s test has ever been false. That tells you whether you`ve ever stopped iterating because you "fell out of the loop". A line coverage tool could only tell you that you`d executed post_loop_cleanup(), not whether you got there because you fell out of the loop or because the internal break statement "broke out of the loop". Maybe you always broke out of the loop. In that case, you have less grounds to be confident that the WHILE test is right.
Ditto for FOR, DO/WHILE, SWITCH/CASE, the ? operator (in C-like languages), etc. (Different coverage tools handle switches in different ways, but all tools I`ve seen that purport to do branch coverage do something with them.)
Except for some special cases, if you exercise all the branches, you`ll exercise all the statements and all the lines. One special case is trivial: what if the program doesn`t contain any branches? (If so, you shouldn`t need a coverage tool to tell you to execute it at least once.) Another is not: what about an exception handler without any branches in its body? I hope that any tool that says it does branch coverage will also tell you about unentered exception handlers.
.........
Source:
http://www.onestoptesting.com/articles/code-coverage/
As someone who`s written four coverage tools, those discussions pain me. They make the whole topic seem over-complicated. To the ordinary person, it`s really simple. There are four relevant types of coverage. They`re all easy to explain. The particular variants implemented by a particular tool have no important practical consequences and are (usually) easily understood.
I describe the four types here.
1. Line Coverage
2. Branch Coverage
3. Condition Coverage
4. Routine Entry Coverage
Line Coverage
Here`s some Java code I wrote recently (or, rather, cribbed from Wirth`s Algorithms + Data Structures = Programs):
1. private Expr orArgument() throws ParseError {
2. Expr retval = factor();
3. while (tokenType == AND) {
4. getsym();
5. retval = new ExprAnd(retval, factor());
6. }
7. tr.debugm(retval.toString());
8. return retval;
9. }
I have a test suite for the application in which this code lives. Suppose I ran that test suite. A line coverage tool could then tell me which of these lines of code had never been reached by the execution of any of my tests.
"Line 4 in file Parser.java was never executed."
(If you`re familiar with source-level debuggers, think of breakpoints. A line coverage tool essentially puts a breakpoint on every line of code. When the breakpoint is hit, it records that fact.)
It`s good to know what lines haven`t been executed. Maybe line 4 should read "factor()" instead of "getsym()". If I never execute it, I`ll never have the chance to find out. (If I do execute it, I might still not find the bug, depending on the test, but at least I have a shot at it.)
In this example, once you know that line 4 hasn`t been executed, you really don`t care to know that line 5 hasn`t been either. It`s obvious. For that reason, some line coverage tools would not tell you about line 5 in that case.
(But such a tool has to be careful not to assume too much: what if getsym() throws a ParseError? Then line 4 has been executed but line 5 has not.)
Most common programming languages aren`t defined in terms of text lines. Instead, their reference manuals talk about statements. If you`ve reached every line of code in the program, have you exercised every statement? Not quite.
Consider this code:
54: if (i < 0) i = 0;
There are two statements there: an IF statement and an assignment statement. A line coverage tool would tell you whether the IF had been reached, but I know of none that would tell you whether the assignment had. I believe that`s for the same reason that most source-level debuggers won`t let you set a breakpoint on the assignment: figuring out a workable user interface is more trouble than it`s worth.
Branch Coverage
Consider:
...
startup();
if (isFun(debating)) {
debate(); debate(); debate();
shutdown();
}
...
If the IF statement is taken false, shutdown() will never be called. That`s probably bad. A line coverage tool won`t tell you that you`ve never taken the ELSE branch because there`s no code in the ELSE branch for it to measure.
So there`s a type of coverage to help. It`s usually called "branch coverage". It checks whether all IF statements have been taken in both the THEN and ELSE directions. Ditto for WHILE statements:
while (i < 33) {
...
if (whatever) break;
...
}
post_loop_cleanup();
A branch coverage tool will tell you whether the WHILE`s test has ever been false. That tells you whether you`ve ever stopped iterating because you "fell out of the loop". A line coverage tool could only tell you that you`d executed post_loop_cleanup(), not whether you got there because you fell out of the loop or because the internal break statement "broke out of the loop". Maybe you always broke out of the loop. In that case, you have less grounds to be confident that the WHILE test is right.
Ditto for FOR, DO/WHILE, SWITCH/CASE, the ? operator (in C-like languages), etc. (Different coverage tools handle switches in different ways, but all tools I`ve seen that purport to do branch coverage do something with them.)
Except for some special cases, if you exercise all the branches, you`ll exercise all the statements and all the lines. One special case is trivial: what if the program doesn`t contain any branches? (If so, you shouldn`t need a coverage tool to tell you to execute it at least once.) Another is not: what about an exception handler without any branches in its body? I hope that any tool that says it does branch coverage will also tell you about unentered exception handlers.
.........
Source:
http://www.onestoptesting.com/articles/code-coverage/