Hi Sergey, Looks like I suggested job which we already have :) so, I think non-voiting coverage job is ok for Sahara project and we can just continue to use it.
Thank you! On Thu, Jul 2, 2015 at 11:06 PM, Sergey Lukjanov <slukja...@mirantis.com> wrote: > Hi Timur, > > I absolutely disagree with this approach. IMO such checks just helps to > organize the unhealthy dev process when contributors will write tests only > to pass this check. We have a non-voting coverage job to track the unit > tests coverage in addition to the code review itself. It's the > responsibility of the core team to ask for additional unit tests if they > are missed. For Sahara project specifically there are tons of places where > unit tests will be just mocks testing and such tests are mostly useless. > For the places not covered by unit tests we have tons of integration tests. > Currently, we trying to force contributors to cover the new code with unit > tests if it's really applicable. > > Let my add some numbers. We have ~ 55% total code coverage by unit tests > and ~70% by integration tests (significantly shifted in terms of code > blocks coverage comparing to the unit tests). If we'll ignore the plugins > dir that contains mostly deployment code fully tested by integration tests > we'll have ~70% unit tests coverage. > > Thanks. > > On Thu, Jul 2, 2015 at 8:55 PM, Timur Nurlygayanov < > tnurlygaya...@mirantis.com> wrote: > >> Hi all, >> >> I suggest to add CI job which will check the unit tests coverage for >> Sahara repository and will set -1 for commits with new code and without >> unit tests (if we have some degradation of tests coverage). >> This job successfully works for Rally project and it helps to organize >> the right code development process when developers write new unit tests for >> new functionality. >> >> we can just copy this job from Rally and start to use it for Sahara: >> Coverage control script: >> https://github.com/openstack/rally/blob/master/tests/ci/cover.sh >> Configuration file for coverage plugin (to exclude code which shouldn't >> be affected): https://github.com/openstack/rally/blob/master/.coveragerc >> Example of job in infra repository: >> https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L4088 >> >> I expect that it will help to increase the tests coverage by unit tests. >> >> Do we have any objections? >> >> -- >> >> Timur, >> Senior QA Engineer >> OpenStack Projects >> Mirantis Inc >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Sincerely yours, > Sergey Lukjanov > Sahara Technical Lead > (OpenStack Data Processing) > Principal Software Engineer > Mirantis Inc. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Timur, Senior QA Engineer OpenStack Projects Mirantis Inc
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev