>> I might like to signal Devel::Cover that func() has a constant return (or >> lack thereof). > > > I don't know if I would like this feature. To me it would allow you to > falsely skew the results of the Devel::Cover output. I look at > Devel::Cover as a harshly objective analysis of my test-code coverage, > anything destroying that objectivity IMO would lessen the value of the > tool.
in general I agree, and if such a feature existed I wouldn't ever use it myself while writing tests or developing code. however, in the process of development we are required to analyze any of the inevitable gaps and decide whether the unhit condition is valid. if it is we write a test for it. if it represents a condition we would explain away (D::C limitation, or whatnot) then it would be nice to have some way to track it within the tool itself. partially to appease management with heavy greens, but more to save development cycles chasing down issues I (or other developers) have analyzed before. > > If you are looking to satisfy management, then I would suggest not > running/showing branch and conditional coverage, as they can be tricky, > and just showing statement and subroutine coverage (and maybe POD too) > since it is much easier to get 100% on those. of course, there is also html editing ;) > Sometimes, too much > information can hurt, and it can be a slippery slope to try and explain > to some why branch/cond coverage sometimes can never be 100%. right. it's a situation we as developers can accept and understand, but for the visually inclined it gets messy. luckily I think it's something everyone can grasp in my current situation :) > To write a test to satisfy the coverage, > but that doesn't actually test the (or any) intended usage, IMO weakens > your overall test. agreed. 100% ;) --Geoff
