Open Stack

David,


1. It will either lead to people doing things to game the system or overuse
> of the #no-coverage-check  tag you mentioned.


Job doesn't force people to increase coverage, it just checks that it was
not decreased.

Btw according to the latest refactoring, we are using absolute values
missing lines, so now we don't need #no-coverage-check at all.


2. It really doesn't tell you too much. A core developer should really be
> looking at the tested use cases to see if they are all there. Line coverage
> and even branch coverage won't tell you that.


It saves a lot of time.

1) I don't want to review patches that are not fully covered by tests (they
just won't be merged in any case).
    Checking by eyes takes in average 2 minutes. I am doing 750 reviews /
release.
    This automation saves about ~25 hours / release, that can be spend on
analyze and reviewing of unit tests code quality.
    If we assume that in

2) It simplify dev process:

    I write my code. Before publishing I just run "tox -ecover" that shows
not fully covered files in my change.

3) It reduce usage of CI hardware and reduce amount of patch sets

    If "tox" runs cover job by default, most developers will make it pass
before sending patch on review.


Best regards,
Boris Pavlovic

On Wed, Apr 22, 2015 at 5:00 PM, David Stanek <dstanek at dstanek.com> wrote:

>
> On Sat, Apr 18, 2015 at 9:30 PM, Boris Pavlovic <boris at pavlovic.me> wrote:
>
>> Code coverage is one of the very important metric of overall code
>> quality especially in case of Python. It's quite important to ensure that
>> code is covered fully with well written unit tests.
>>
>> One of the nice thing is coverage job.
>>
>
> I really like the idea of adding the coverage job everywhere so that
> developers can view the results be using a link in Gerrit. I think this
> would make it easier for many.
>
> I don't like the idea of checking that coverage is increased. There are
> many issues with that. The two biggest one for me are:
>
> 1. It will either lead to people doing things to game the system or
> overuse of the #no-coverage-check  tag you mentioned.
>
> 2. It really doesn't tell you too much. A core developer should really be
> looking at the tested use cases to see if they are all there. Line coverage
> and even branch coverage won't tell you that.
>
>
> --
> David
> blog: http://www.traceback.org
> twitter: http://twitter.com/dstanek
> www: http://dstanek.com
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150422/d082a4b5/attachment.html>