<div dir="ltr">Ian, <div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">If you were thinking instead to provide coverage *tools* that were easy for developers to use,</span></blockquote><div><br></div><div>Hm, seems like you missed the point. This "gate job" can be run like unit tests "tox -e cover". That will point you on the missing lines that are introduced in your patch. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">  As a dev, I would not be terribly interested in finding that I've improved overall test coverage from 90.1% to 90.2%</span></blockquote><div> </div><div>It is not the goal of the job that I add. Job checks that your patch don't introduce code that is not covered by unit test (that is all). </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">but I might be *very* interested to know that I got 100% decision (or even boolean) coverage on the specific lines of the feature I just added by running just the unit tests that exercise it.</span></blockquote><div><br></div><div>And this is exactly what "tox -e cover" does and job that run tox -e cover in gates. </div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 21, 2015 at 3:28 AM, Ian Wells <span dir="ltr"><<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On 20 April 2015 at 07:40, Boris Pavlovic <span dir="ltr"><<a href="mailto:boris@pavlovic.me" target="_blank">boris@pavlovic.me</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dan, <span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">IMHO, most of the test coverage we have for nova's neutronapi is more<br></span><span style="font-size:12.8px">than useless. It's so synthetic that it provides no regression<br></span><span style="font-size:12.8px">protection, and often requires significantly more work than the change<br></span><span style="font-size:12.8px">that is actually being added. It's a huge maintenance burden with very<br></span><span style="font-size:12.8px">little value, IMHO. Good tests for that code would be very valuable of<br></span><span style="font-size:12.8px">course, but what is there now is not.</span><br style="font-size:12.8px"><span style="font-size:12.8px">I think there are cases where going from 90 to 91% mean adding a ton of<br></span><span style="font-size:12.8px">extra spaghetti just to satisfy a bot, which actually adds nothing but<br></span><span style="font-size:12.8px">bloat to maintain.</span></blockquote><div><br></div></span><div>Let's not mix the bad unit tests in Nova with the fact that code should be fully covered by well written unit tests. </div><div>This big task can be split into 2 smaller tasks: <br></div><div>1) Bot that will check that we are covering new code by tests and don't introduce regressions </div></div></blockquote></span><div><br><a href="http://en.wikipedia.org/wiki/Code_coverage" target="_blank">http://en.wikipedia.org/wiki/Code_coverage</a><br><br></div><div>You appear to be talking about statement coverage, which is one of the weaker coverage metrics.<br><br></div><div>    if a:<br></div><div>        thing<br><br></div><div>gets 100% statement coverage if a is true, so I don't need to test when a is false (which would be at a minimum decision coverage).<br></div><div><br></div>I wonder if the focus is wrong.  Maybe helping devs is better than making more gate jobs, for starters; and maybe overall coverage is not a great metric when you're changing 100 lines in 100,000.  If you were thinking instead to provide coverage *tools* that were easy for developers to use, that would be a different question.  As a dev, I would not be terribly interested in finding that I've improved overall test coverage from 90.1% to 90.2%, but I might be *very* interested to know that I got 100% decision (or even boolean) coverage on the specific lines of the feature I just added by running just the unit tests that exercise it.<span class="HOEnZb"><font color="#888888"><br><div>-- <br></div><div>Ian.<br></div><div><br></div><br></font></span></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>