<div>If you let me know in a bit more detail what you're looking for, I can probably whip something up.  Email me direct?</div><div><br></div><div>Justin<br></div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 25, 2012 at 6:59 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On 04/24/2012 10:08 PM, Lorin Hochstein wrote:<br>
><br>
> On Apr 24, 2012, at 4:11 PM, Joe Gordon wrote:<br>
><br>
>> Hi All,<br>
>><br>
>> I would like to propose a minimum required code coverage level per<br>
>> file in Nova.  Say 80%.  This would mean that any new feature/file<br>
>> should only be accepted if it has over 80% code coverage.  Exceptions<br>
>> to this rule would be allowed for code that is covered by skipped<br>
>> tests (as long as 80% is reached when the tests are not skipped).<br>
>><br>
><br>
> I like the idea of looking at code coverage numbers. For any particular<br>
> merge proposal, I'd also like to know whether it increases or decreases<br>
> the overall code coverage of the project. I don't think we should gate<br>
> on this, but it would be helpful for a reviewer to see that, especially<br>
> for larger proposals.<br>
<br>
</div>Yup... Nati requested this a couple of summits ago - main issue is that<br>
while we run code coverage and use the jenkins code coverage plugin to<br>
track the coverage numbers, the plugin doesn't fully support this<br>
particular kind of report.<br>
<br>
HOWEVER - if any of our fine java friends out there want to chat with me<br>
about adding support to the jenkins code coverage plugin to track and<br>
report this, I will be thrilled to put it in as a piece of reported<br>
information.<br>
<div class="im"><br>
>> With 193 python files in nova/tests, Nova unit tests produce 85%<br>
>> overall code coverage (calculated with ./run_test.sh -c [1]).  But 23%<br>
>> of files (125 files) have lower then 80% code coverage (30 tests<br>
>> skipped on my machine).  Getting all files to hit the 80% code<br>
>> coverage mark should be one of the goals for Folsom.<br>
>><br>
><br>
> I would really like to see a visualization of the code coverage<br>
> distribution, in order to help spot the outliers.<br>
><br>
><br>
> Along these lines, there's been a lot of work in the software<br>
> engineering research community about predicting which parts of the code<br>
> are most likely to contain bugs ("fault prone" is a good keyword to find<br>
> this stuff, e.g.: <a href="http://scholar.google.com/scholar?q=fault+prone" target="_blank">http://scholar.google.com/scholar?q=fault+prone</a>, big<br>
> names include Nachi Nagappan at MS Research and Elaine Weyuker, formerly<br>
> of AT&T Research). I would *love* to see some academic researchers try<br>
> to apply those techniques to OpenStack to help guide QA activities by<br>
> identifying which parts of the code should get more rigorous  testing<br>
> and review.<br>
<br>
</div>++<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br></div></div>