StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Much of the problem here is the insistence on getting 100% execution coverage of "lines". (Managers like this idea; it is a simple model they can understand). Many lines aren't "executable" (whitespace, gaps between function declarations, comments, declarations, "pure syntax" e.g., the closing "}" of a switch or class declaration, or complex statements split across multiple source lines).</p> <p>What you really want to know is, "is all the <em>executable</em> code covered?" This distinction seems silly yet leads to a solution. XDebug tracks what gets executed, well, by line number and your XDebug-based scheme thus reports ranges of executed lines. And you get the troubles discussed in this thread, including the klunky solutions of having to annotate the code with "don't count me" comments, putting "}" on the same line as the last executable statement, etc. No programmer is really willing to do that let alone maintain it.</p> <p>If one defines executable code as that code which which can be called or is controlled by a conditional (what the compiler people call "basic blocks"), and the coverage tracking is done that way, then the layout of the code and the silly cases simply disappear. A test coverage tool of this type collects what is called "branch coverage", and you can get or not get 100% "branch coverage" literally by executing all the executable code. In addition, it will pick up those funny cases where you have a conditional within a line (using "x?y:z") or in which you have two conventional statements in a line (e.g.,</p> <pre><code> if (...) { if (...) stmt1; else stmt2; stmt3 } </code></pre> <p>Since XDebug tracks by line, I beleive it treats this as one statment, and considers it coverage if control gets to the line, when in fact there are 5 parts to actually test.</p> <p>Our <a href="http://www.semanticdesigns.com/Products/TestCoverage/PHPTestCoverage.html" rel="nofollow">PHP Test Coverage tool</a> implements these ideas. In particular, it understands that code following a return statement isn't executable, and it will tell you that you haven't executed it, if it is non-empty. That makes the OP's original problem just vanish. No more playing games to get "real" coverage numbers.</p> <p>As with all choices, sometimes there is a downside. Our tool has a code instrument component that only runs under Windows; instrumented PHP code can run anywhere and the processing/display is done by a platform independent Java program. So this might be awkward for OP's OSX system. The instrumenter works fine across NFS-capable file systems, so he could arguably run the instrumenter on a PC and instrument his OSX files.</p> <p>This particular problem was raised by someone trying to push his coverage numbers up; the problem was IMHO artificial and can be cured by stepping around the artificiality. There's another way to push up your numbers without writing more tests, and that's finding and removing duplicate code. If you remove duplicates, there's less code to test and testing one (non)copy in effects tests the (now nonexistent other copy) so it is easier to get higher numbers. You can <a href="http://www.semdesigns.com/Products/TestCoverage/ImprovingTestCoverage.html#RemoveClones" rel="nofollow">read more about this here.</a></p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload