| Message ID | 1442933973-23527-1-git-send-email-damien.lespiau@intel.com |
|---|---|
| State | Accepted |
| Headers | show |
> Having the tests in the coverage reports artifically improve the > coverage percentage, because every line in tests is being run. > > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Good point. Reviewed-by: Stephen Finucane <stephen.finucane@intel.com>
> > Having the tests in the coverage reports artifically improve the > > coverage percentage, because every line in tests is being run. > > > > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> > > Good point. > > Reviewed-by: Stephen Finucane <stephen.finucane@intel.com> As an aside, still so much work to be done upping coverage :O PEP8 compliance and features first though.
On Tue, Sep 22, 2015 at 04:43:17PM +0100, Finucane, Stephen wrote: > > > Having the tests in the coverage reports artifically improve the > > > coverage percentage, because every line in tests is being run. > > > > > > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> > > > > Good point. > > > > Reviewed-by: Stephen Finucane <stephen.finucane@intel.com> > > As an aside, still so much work to be done upping coverage :O PEP8 > compliance and features first though. I don't think PEP8 is a priority, it creates more pain than gain at the moment because so many patches are in flight.
> On Tue, Sep 22, 2015 at 04:43:17PM +0100, Finucane, Stephen wrote: > > > > Having the tests in the coverage reports artifically improve the > > > > coverage percentage, because every line in tests is being run. > > > > > > > > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> > > > > > > Good point. > > > > > > Reviewed-by: Stephen Finucane <stephen.finucane@intel.com> > > > > As an aside, still so much work to be done upping coverage :O PEP8 > > compliance and features first though. > > I don't think PEP8 is a priority, it creates more pain than gain at the > moment because so many patches are in flight. Yes and no. No for files touched by existing submitted patches (features and bug fixes >>> style) but yes for all other files. Patches that improve code quality are a good thing. Stephen
On Tue, Sep 22, 2015 at 05:31:23PM +0100, Finucane, Stephen wrote: > > On Tue, Sep 22, 2015 at 04:43:17PM +0100, Finucane, Stephen wrote: > > > > > Having the tests in the coverage reports artifically improve the > > > > > coverage percentage, because every line in tests is being run. > > > > > > > > > > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> > > > > > > > > Good point. > > > > > > > > Reviewed-by: Stephen Finucane <stephen.finucane@intel.com> > > > > > > As an aside, still so much work to be done upping coverage :O PEP8 > > > compliance and features first though. > > > > I don't think PEP8 is a priority, it creates more pain than gain at the > > moment because so many patches are in flight. > > Yes and no. No for files touched by existing submitted patches > (features and bug fixes >>> style) but yes for all other files. > Patches that improve code quality are a good thing. I'm not saying it's a bad thing, but that it does make rebasing patches harder.
> On Tue, Sep 22, 2015 at 05:31:23PM +0100, Finucane, Stephen wrote: > > > On Tue, Sep 22, 2015 at 04:43:17PM +0100, Finucane, Stephen wrote: > > > > > > Having the tests in the coverage reports artifically improve the > > > > > > coverage percentage, because every line in tests is being run. > > > > > > > > > > > > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> > > > > > > > > > > Good point. > > > > > > > > > > Reviewed-by: Stephen Finucane <stephen.finucane@intel.com> > > > > > > > > As an aside, still so much work to be done upping coverage :O PEP8 > > > > compliance and features first though. > > > > > > I don't think PEP8 is a priority, it creates more pain than gain at the > > > moment because so many patches are in flight. > > > > Yes and no. No for files touched by existing submitted patches > > (features and bug fixes >>> style) but yes for all other files. > > Patches that improve code quality are a good thing. > > I'm not saying it's a bad thing, but that it does make rebasing patches > harder. Sorry, the point I was making is I don't think any PEP8 changes I've personally made touch files modified as part of (submitted) patches from other contributors? The one exception here is 'models.py' in the "test status" series, but that badly needed work. I'll continue this trend going forward. Stephen
On Tue, Sep 22, 2015 at 04:39:01PM +0100, Finucane, Stephen wrote: > > Having the tests in the coverage reports artifically improve the > > coverage percentage, because every line in tests is being run. > > > > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> > > Good point. > > Reviewed-by: Stephen Finucane <stephen.finucane@intel.com> Picked up for the next pull request. Thanks for the review!
> On Tue, Sep 22, 2015 at 04:39:01PM +0100, Finucane, Stephen wrote: > > > Having the tests in the coverage reports artifically improve the > > > coverage percentage, because every line in tests is being run. > > > > > > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> > > > > Good point. > > > > Reviewed-by: Stephen Finucane <stephen.finucane@intel.com> > > Picked up for the next pull request. Thanks for the review! > > -- > Damien Merged.
diff --git a/tox.ini b/tox.ini index 891fc5e..53d067e 100644 --- a/tox.ini +++ b/tox.ini @@ -44,5 +44,6 @@ setenv = DJANGO_SETTINGS_MODULE = patchwork.settings.dev commands = coverage erase - coverage run --omit=*tox* --branch {toxinidir}/manage.py test patchwork + coverage run --omit=*tox*,patchwork/tests/*.py,manage.py --branch \ + {toxinidir}/manage.py test patchwork coverage report -m
Having the tests in the coverage reports artifically improve the coverage percentage, because every line in tests is being run. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> --- tox.ini | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)