183
edits
CodeCoverage/Firefly: Difference between revisions
no edit summary
Mnandigama (talk | contribs) No edit summary |
Mnandigama (talk | contribs) No edit summary |
||
| Line 21: | Line 21: | ||
However, if you are provided an additional data point, like size of the component, you may realize that filling a 40% coverage gap in say '''Content''' gives you a bigger bang for the buck than improving 100% code coverage in '''xpinstall'''. [Side note: This data is generated on Linux so, there would be no coverage for '''xpinstall'''] | However, if you are provided an additional data point, like size of the component, you may realize that filling a 40% coverage gap in say '''Content''' gives you a bigger bang for the buck than improving 100% code coverage in '''xpinstall'''. [Side note: This data is generated on Linux so, there would be no coverage for '''xpinstall'''] | ||
[[Image:Covdatafilesize.PNG|center|Component sizes : Number of files in a component]] | [[Image:Covdatafilesize.PNG|center|Component sizes : Number of files in a component]] | ||
Based on the data from additional data point, you can clearly see that '''content''', '''layout''' code coverage improvements give more bang for the buck. | |||
But which files among those hundreds of files need first attention !! | |||
=== Additional pointers for a better decision analysis === | |||
If, for each file, in a given component, we have additional data pointers like number of bugs fixed for each file, the number of regression bugs fixed, number of security bugs fixed, number of crash bugs fixed, manual code coverage, branch coverage etc., we can stack rank the files in a given component based on any of those points. | |||
== How == | == How == | ||