1Devel::Cover::Tutorial(U3s)er Contributed Perl DocumentatDieovnel::Cover::Tutorial(3)
2
6 Here's part of a message I sent to perl-qa about code coverage metrics.
7 1.0 Introduction
9 It is wise to remember the following quote from Dijkstra, who said:
11 Testing never proves the absence of faults, it only shows their presence.
13 In particular, code coverage is just one weapon in the software engi‐
15 neer's testing arsenal.
16 Any discussion of code coverage metrics is hampered by the fact that
18 many authors use different terms to describe the same kind of coverage.
19 Here, I shall provide only a brief introduction to some of the most
20 common metrics.
21 2.0 Metrics
23 2.1 Statement coverage
25 This is the most basic form of code coverage. A statement is covered
27 if it is executed. Note that statement != line of code. Multiple
28 statements on a single line can confuse issues - the reporting if noth‐
29 ing else.
30 Where there are sequences of statements without branches it is not nec‐
32 essary to count the execution of every statement, just one will suf‐
33 fice, but people often like the count of every line to be reported,
34 especially in summary statistics. However it is not clear to me that
35 this is actually useful.
36 This type of coverage is fairly weak in that even with 100% statement
38 coverage there may still be serious problems in a program which could
39 be discovered through other types of metric.
40 It can be quite difficult to achieve 100% statement coverage. There
42 may be sections of code designed to deal with error conditions, or
43 rarely occurring events such as a signal received during a certain sec‐
44 tion of code. There may also be code that should never be executed:
45 if ($param > 20)
47 {
48 die "This should never happen!";
49 }
50 It can be useful to mark such code in some way and flag an error if it
52 is executed.
53 Statement coverage, or something very similar, can be called statement
55 execution, line, block, basic block or segment coverage. I tend to
56 favour block coverage which does not attempt to extend its results to
57 each statement.
58 2.2 Branch coverage
60 The goal of branch coverage is to ensure that whenever a program can
62 jump, it jumps to all possible destinations. The most simple example
63 is a complete if statement:
64 if ($x)
66 {
67 print "a";
68 }
69 else
70 {
71 print "b";
72 }
73 In such a simple example statement coverage is as powerful, but branch
75 coverage should also allow for the case where the else part is missing:
76 if ($x)
78 {
79 print "a";
80 }
81 Full coverage is only achieved here if $x is true on one occasion and
83 false on another.
84 100% branch coverage implies 100% statement coverage.
86 Branch coverage is also called decision or all edges coverage.
88 2.3 Path coverage
90 There are classes of errors that branch coverage cannot detect, such
92 as:
93 $h = undef;
95 if ($x)
96 {
97 $h = { a => 1 };
98 }
99 if ($y)
100 {
101 print $h->{a};
102 }
103 100% branch coverage can be achieved by setting ($x, $y) to (1, 1) and
105 then to (0, 0). But if we have (0, 1) then things go bang.
106 The purpose of path coverage is to ensure that all paths through the
108 program are taken. In any reasonably sized program there will be an
109 enormous number of paths through the program and so in practice the
110 paths can be limited to a single subroutine, if the subroutine is not
111 too big, or simply to two consecutive branches.
112 In the above example there are four paths which correspond to the truth
114 table for $x and $y. To achieve 100% path coverage they must all be
115 taken. Note that missing elses count as paths.
116 In some cases it may be impossible to achieve 100% path coverage:
118 a if $x;
120 b;
121 c if $x;
122 50% path coverage is the best you can get here.
124 Loops also contribute to paths, and pose their own problems which I'll
126 ignore for now.
127 100% path coverage implies 100% branch coverage.
129 Path coverage and some of its close cousins, are also known as predi‐
131 cate, basis path and LCSAJ (Linear Code Sequence and Jump) coverage.
132 2.4 Expression coverage
134 When a boolean expression is evaluated it can be useful to ensure that
136 all the terms in the expression are exercised. For example:
137 a if $x ⎪⎪ $y
139 The expression should be exercised with ($x, $y) set to (0, 0)
141 (required for branch coverage), (0, 1) and (1, 0) (to ensure that $x
142 and $y are independent) and possibly with (1, 1).
143 Expression coverage gets complicated, and difficult to achieve, as the
145 expression gets complicated.
146 Expressions which are not directly a part of a branching construct
148 should also be covered:
149 $z = $x ⎪⎪ $y;
151 a if $z;
152 Expression coverage is also known as condition, condition-decision and
154 multiple decision coverage.
155 3.0 Other considerations
157 In order to get people to actually use code coverage it needs to be
159 simple to use. It should also be simple to understand the results and
160 to rectify any problems thrown up. Finally, if the overhead is too
161 great it won't get used either.
162 So there's a basic tutorial on code coverage, or at least my version of
164 it. Typing a few of these terms into google will probably provide a
165 basis for future research.
166
168 Version 0.61 - 10th January 2007
169
171 Copyright 2001-2007, Paul Johnson (pjcj@cpan.org)
172 This software is free. It is licensed under the same terms as Perl
174 itself.
175 The latest version of this software should be available from my home‐
177 page: http://www.pjcj.net
178perl v5.8.8 2007-01-10 Devel::Cover::Tutorial(3)