On Mon, Jul 11, 2005 at 08:28:01PM -0600, Jim Cromie wrote: > 1. emit a text version of the coverage failures which > a. has same info as html details - ie line# conditionals, code > b. starts with a comment. > > 2. use that 'exact' format as your ignore directive > a. except that # means its entirely ignored > b. user removes # to cause report supression > > now, full power (and a bit of tedium) is in users hands. > by just renaming the output to .uncoverable (or whatever), > they get a do-nothing version thats up-to-date with their code, > and thats easy to use to supress everything. > You could call it a feature that line-changes invalidate supressions, > since the code being tested has changed ;-)
No, this is as silly as saying TODO tests should have to all be reencoded every time you edit the test. You're causing the programmer to have to redo a task every time the file is edited. Not only is this a collosal waste of time and likely to make the programmer just give up on coverage or worrying about keeping .uncoverable up to date but, as with any rote task performed by humans, its an invitation to mistakes. > Adding pattern matching on line # is easy, and would make the .uncoverable > file a bit more flexible, you probly want \Q \E around the code itself, > with loud caveats about not doing intelligent src-code matching. > > Hey, its supression, it shouldnt be too easy. FALSE! Making supression hard will cause them to not want to supress. The end result being... what? That they write code in a style which Devel::Cover likes? Is that an improvement, coding to satisfy the quirks of your analysis tools? More likely they'll just give up on maintaining .uncoverable and live with the false negatives, an outcome we do not want. > And updating supression files shouldnt be a daily occurrence, Yes it should. It should happen as the programmer spots the mis-coverage, otherwise they're going to forget. Coverage analysis, like testing, is part of the development process to be continually used to prevent and catch bugs early and speed development, not a "just before release" check. The attitude that this should be a hard thing reveals that one does not trust the programmer not to abuse the uncoverable option and to put road blocks in the way. This is a losing attitude. If you don't trust the programmer not to try and fool their analysis tools, if they haven't "bought in" to the process, if they're consciously trying to sabotogue the system, making .uncoverable a little difficult to use is the least of your worries. There's a bazillion other ways a renegade programmer can sabotoge their analysis tools. Making the tools harder to use will just lead to more resentment. In the end, you have to trust your programmer. Don't try to solve social issues with technology. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
