{
    "content": [
        {
            "type": "text",
            "text": "# Devel::Cover::Tutorial (perldoc)\n\n**Summary:** Devel::Cover::Tutorial - An introduction to code coverage\n\n## Section Outline\n\n- **NAME** (2 lines)\n- **VERSION** (2 lines)\n- **TUTORIAL** (145 lines)\n- **LICENCE** (8 lines)\n\n## Full Content\n\n### NAME\n\nDevel::Cover::Tutorial - An introduction to code coverage\n\n### VERSION\n\nversion 1.36\n\n### TUTORIAL\n\nHere's part of a message I sent to perl-qa about code coverage metrics.\n\n1.0 Introduction\nIt is wise to remember the following quote from Dijkstra, who said:\n\nTesting never proves the absence of faults, it only shows their presence.\n\nIn particular, code coverage is just one weapon in the software\nengineer's testing arsenal.\n\nAny discussion of code coverage metrics is hampered by the fact that\nmany authors use different terms to describe the same kind of coverage.\nHere, I shall provide only a brief introduction to some of the most\ncommon metrics.\n\n2.0 Metrics\n2.1 Statement coverage\nThis is the most basic form of code coverage. A statement is covered if\nit is executed. Note that statement != line of code. Multiple statements\non a single line can confuse issues - the reporting if nothing else.\n\nWhere there are sequences of statements without branches it is not\nnecessary to count the execution of every statement, just one will\nsuffice, but people often like the count of every line to be reported,\nespecially in summary statistics. However it is not clear to me that\nthis is actually useful.\n\nThis type of coverage is fairly weak in that even with 100% statement\ncoverage there may still be serious problems in a program which could be\ndiscovered through other types of metric.\n\nIt can be quite difficult to achieve 100% statement coverage. There may\nbe sections of code designed to deal with error conditions, or rarely\noccurring events such as a signal received during a certain section of\ncode. There may also be code that should never be executed:\n\nif ($param > 20) {\ndie \"This should never happen!\";\n}\n\nIt can be useful to mark such code in some way and flag an error if it\nis executed.\n\nStatement coverage, or something very similar, can be called statement\nexecution, line, block, basic block or segment coverage. I tend to\nfavour block coverage which does not attempt to extend its results to\neach statement.\n\n2.2 Branch coverage\nThe goal of branch coverage is to ensure that whenever a program can\njump, it jumps to all possible destinations. The most simple example is\na complete if statement:\n\nif ($x) {\nprint \"a\";\n} else {\nprint \"b\";\n}\n\nIn such a simple example statement coverage is as powerful, but branch\ncoverage should also allow for the case where the else part is missing:\n\nif ($x) {\nprint \"a\";\n}\n\nFull coverage is only achieved here if $x is true on one occasion and\nfalse on another.\n\n100% branch coverage implies 100% statement coverage.\n\nBranch coverage is also called decision or all edges coverage.\n\n2.3 Path coverage\nThere are classes of errors that branch coverage cannot detect, such as:\n\n$h = undef;\nif ($x) {\n$h = { a => 1 };\n} if ($y) {\nprint $h->{a};\n}\n\n100% branch coverage can be achieved by setting ($x, $y) to (1, 1) and\nthen to (0, 0). But if we have (0, 1) then things go bang.\n\nThe purpose of path coverage is to ensure that all paths through the\nprogram are taken. In any reasonably sized program there will be an\nenormous number of paths through the program and so in practice the\npaths can be limited to a single subroutine, if the subroutine is not\ntoo big, or simply to two consecutive branches.\n\nIn the above example there are four paths which correspond to the truth\ntable for $x and $y. To achieve 100% path coverage they must all be\ntaken. Note that missing elses count as paths.\n\nIn some cases it may be impossible to achieve 100% path coverage:\n\na if $x;\nb;\nc if $x;\n\n50% path coverage is the best you can get here.\n\nLoops also contribute to paths, and pose their own problems which I'll\nignore for now.\n\n100% path coverage implies 100% branch coverage.\n\nPath coverage and some of its close cousins, are also known as\npredicate, basis path and LCSAJ (Linear Code Sequence and Jump)\ncoverage.\n\n2.4 Expression coverage\nWhen a boolean expression is evaluated it can be useful to ensure that\nall the terms in the expression are exercised. For example:\n\na if $x || $y\n\nThe expression should be exercised with ($x, $y) set to (0, 0) (required\nfor branch coverage), (0, 1) and (1, 0) (to ensure that $x and $y are\nindependent) and possibly with (1, 1).\n\nExpression coverage gets complicated, and difficult to achieve, as the\nexpression gets complicated.\n\nExpressions which are not directly a part of a branching construct\nshould also be covered:\n\n$z = $x || $y;\na if $z;\n\nExpression coverage is also known as condition, condition-decision and\nmultiple decision coverage.\n\n3.0 Other considerations\nIn order to get people to actually use code coverage it needs to be\nsimple to use. It should also be simple to understand the results and to\nrectify any problems thrown up. Finally, if the overhead is too great it\nwon't get used either.\n\nSo there's a basic tutorial on code coverage, or at least my version of\nit. Typing a few of these terms into google will probably provide a\nbasis for future research.\n\n### LICENCE\n\nCopyright 2001-2019, Paul Johnson (paul@pjcj.net)\n\nThis software is free. It is licensed under the same terms as Perl\nitself.\n\nThe latest version of this software should be available from my\nhomepage: http://www.pjcj.net\n\n"
        }
    ],
    "structuredContent": {
        "command": "Devel::Cover::Tutorial",
        "section": "",
        "mode": "perldoc",
        "summary": "Devel::Cover::Tutorial - An introduction to code coverage",
        "synopsis": null,
        "flags": [],
        "examples": [],
        "see_also": [],
        "section_outline": [
            {
                "name": "NAME",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "VERSION",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "TUTORIAL",
                "lines": 145,
                "subsections": []
            },
            {
                "name": "LICENCE",
                "lines": 8,
                "subsections": []
            }
        ]
    }
}