<div dir="ltr">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><div class="gmail_extra"><div class="gmail_quote"><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 class=""><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><div><br><a href="http://en.wikipedia.org/wiki/Code_coverage">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.<br><div>-- <br></div><div>Ian.<br></div><div><br></div><br></div></div></div>