On Wed, Dec 20, 2006 at 08:31:44AM -0500, Michael G Schwern wrote: > Paul Johnson wrote: > > That would be the "uncoverable" feature, which I haven't quite finished > > yet. It does just what is asked for, that is you can mark constructs as > > uncoverable which means that the sense of the error is reversed - the > > construct will be in error iff it is executed. > > > > There are three main sections of work still left to be completed: > > > > 1. Find some nice way expressing what is uncoverable. For subroutines > > this is easy. For statements it is not hard. For branches it is > > tricky and for conditions I'm somewhat stumped. The current > > method I use is based on implementation details. > > What's the current syntaxes you're toying with?
from tests/.uncoverable: tests/uncoverable statement 20f752895295d69b6b73da4d9921a9ed 0 0 Can't get to this statement tests/uncoverable statement 89c43a57239a432b0517549f6b8f9feb 0 0 Can't get to this statement tests/uncoverable statement ba33ccd5188f01ebbd59be35038fe0cb 0 0 Can't get to this statement tests/uncoverable branch 9389290602dbf70585e0467e6cb28669 0 0 Branch can't be true tests/uncoverable condition 9389290602dbf70585e0467e6cb28669 0 0 $x can't be false tests/uncoverable condition 9389290602dbf70585e0467e6cb28669 0 2 $y can't be false tests/uncoverable subroutine ba33ccd5188f01ebbd59be35038fe0cb 0 0 Can't run this subroutine that is: file, criterion, md5 of line, count (nth such construct on the line), type (identification of the part of the branch or condition) reason The bit that really needs work is the type field. How can you easily specify which part of a branch or which part of a condition is uncoverable? > > 3. Provide a way to specify uncoverable code within the source file. > > I'm surprised that many people want this, but they do. > > Do you mean so we can mark what lines and things are uncoverable inline? > Right next to the code itself? Of course! What would the alternative be? At the moment, $ cover -add_uncoverable_point "tests/uncoverable statement 73 0 0 Can't get to this statement" I sometimes dream of some AJAX driven, fully buzzword compliant gui which would let you navigate your results without having to create acres of static HTML, and which would allow you to specify this sort of thing in the gui. But I'm learning that I really shouldn't eat cheese before going to bed. I suspect that the sets of those who would annotate uncoverable code inline, those who would use a separate file and those who wouldn't bother at all probably correlates fairly well with those who add pod inline, those who add it at the end or separately and those who don't document at all. Well, maybe not exactly - I can probably make good arguments for inline annotation. But I'm probably just scarred by using too many tools that insist I change my source code to make up for their inadequacies. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
