History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: BCOV-24
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Dan Grabowski
Reporter: Dan Grabowski
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Bamboo Coverage Plugin

Allow user to configure preferred coverage granularity

Created: 11/Jun/07 11:23 PM   Updated: 11/Jun/07 11:33 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
Reference
 

Labels:


 Description  « Hide
Currently, each code coverage provider (emma, clover, or cobertura) has a preferred code coverage granularity (line, block, statement, class, etc.) that is hard-coded into the provider implementation. This preferred granularity is used throughout the plugin where it is not feasible to take statistics for all of the available granularities into account. For example, when summarizing the build's code coverage into a single percentage or charting coverage deltas by author. In cases like these, taking all of the granularities into account does not align with the purpose of the functionality or would make the information presented too verbose and confusing.

It would be nice if the preferred granularity could be configured by the user for each build. This would allow users to focus on the code coverage statistic that they find most useful or critical. In particular, the EMMA provider could benefit from this feature, because line coverage statistics (the original preferred granularity for this provider) are not always available for reasons described in BCOV-23.



 All   Comments   Work Log   Change History   FishEye   Crucible   Related Builds      Sort Order: Ascending order - Click to sort in descending order
Dan Grabowski - 11/Jun/07 11:25 PM
Making the preferred granularity user-configurable would resolve the emma provider's issue with line coverage statistics not always being available.

Dan Grabowski - 11/Jun/07 11:33 PM
The biggest hurdle to implementing this is figuring out how to provide the user with the correct choices on the builder configuration page. The list of options for preferred granularity is dependent on the value selected for the code coverage provider. Alternatively, the full list of possible granularities could be presented, and the user could be informed by a validation error message after the fact that their selection is not compatible with their coverage provider of choice. This does go against the "do make me think" principle of user interface design, however.

Another consideration that needs to be factored in is the behavior of the plugin if there are no statistics available for the preferred granularity selected.