On 5/27/2004 9:31 AM, Paul Johnson wrote: > On Fri, May 21, 2004 at 12:50:55PM -0400, Geoffrey Young wrote: >> >> if [a missed path] 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. > > It has always been my plan to include something along these lines. > > I have just released Devel::Cover 0.45 and I've included some code which is > working towards a solution in this area. The code seems to work, but there is > no (reasonable) user interface for it, and it is not documented at all. > > Of course, this was not obvious to Michael when he wrote the html output > backend, and so the colours there are dictated by the percentage
I've started playing with this. I've hacked up the top-level summary to choose colors based on "satisfied" coverage, where "satisfied" means that either a) you've actually covered the path, or b) you've written an analysis for a missed path Before I get too deep into an implementation, I'd like to poll the group about how you would use this feature and like it to behave. My thoughts and plans follow. For the coverage summary, the numbers represent actual coverage, but the colors are based upon actual coverage + analysis. So it's possible to have (e.g.) a green 66.7 in the 'cond' column. Tooltips have changed from "N / T" (covered paths / total paths) to "T paths: N covered, M analyzed". I plan to do the same thing with the totals for the detailed reports as well as the percentages for an individual line in the detailed reports (only without the tooltips). The only thing I don't like about this approach is that some of the data is available only in the tooltips, which of course don't print. Do people make hardcopies of these reports? If so, would you want the extra data in them? For the bodies of the detailed coverage reports, I plan to add a new color-coding for analyzed paths. (Probably a light grey fill, or maybe no (white) fill with greyed-out text.) Analyzed paths will either a) have a tooltip to display the analysis, or b) become a hyperlink to a page containing the code and analysis. I'm leaning toward (b) because it's possible that an analysis could get too long to show in a tooltip, and because that would provide a way of producing a hardcopy report including analysis. > Michael has some ideas for backends and interfaces to the uncoverable code, > which I'll let him talk about or work on as he sees fit. I plan to get the backend working before I start messing with the UI. CGI would be the slickest -- you could do everything from the report. But that would require a webserver, which I'm loathe to do. (I may relent if anyone knows of a small, simple, lightweight pure-perl server that could be started/stopped as needed.) My current plan is to create a command-line based tool for entering the data, and provide a Tk app as a wrapper. The intent would be for people to use the Tk interface with the command-line interface provided for those unable/unwilling to install Tk or in case someone wants a scriptable interface. -mjc
