--with-coverage starts going after models are already imported #2

Closed
jbalogh opened this Issue Dec 15, 2009 · 29 comments

Comments

Projects
None yet
Contributor

jbalogh commented Dec 15, 2009

Coverage-tracking should start immediately, or else it looks like your models didn't get run at all.

Looks like you fixed this?

Contributor

jbalogh commented Dec 22, 2009

It's only fixed in hudson because we're running everything through bin/coverage, but I'd like to see if there's a better way.

Contributor

rozza commented Jun 28, 2010

Fixed in: http://github.com/rozza/django-nose - please pull.

Contributor

carljm commented Jul 14, 2010

I can confirm that rozza's branch fixes this, works well, tests pass.

Contributor

jbalogh commented Jul 14, 2010

Tweaked and added in http://github.com/jbalogh/django-nose/commit/29f3092313. Thanks for the patch!

Sorry about the long long delay, I've had other projects in my head.

reinout commented Aug 5, 2010

Just got bitten by this bug as the django-nose version on pypi hasn't been updated.

Is a new release planned?

Contributor

jbalogh commented Aug 5, 2010

This was held up by http://github.com/jbalogh/django-nose/issues/19, but it should be ok now.

You can run your tests through coverage run manage.py test to get full coverage in the meantime.

Contributor

ipmb commented Aug 18, 2010

I don't think this is fixed. I tested with a base Django project and got the following results.

With django-nose coverage:

$ ./manage.py test --with-coverage --cover-package=django.contrib.auth.models django.contrib.auth
Name                         Stmts   Exec  Cover   Missing
----------------------------------------------------------
django.contrib.auth.models     273     98    35%   1-16, 23-27, 30, 33-35, 43-105, 116-117, 128, 132-149, 165, 180, 190-215, 218-221, 228, 235-240, 247, 255-260, 263-270, 289, 292, 311, 322, 328, 331, 335-347, 370-371, 373-408, 411, 414-449, 452, 455, 461, 464-467, 470
----------------------------------------------------------------------
Ran 45 tests in 1.368s

OK

With external coverage:

$ coverage -x ./manage.py test django.contrib.auth
$ coverage report --show-missing ../lib/python2.6/site-packages/django/contrib/auth/models.py
Name                                                        Stmts   Exec  Cover   Missing
-----------------------------------------------------------------------------------------
../lib/python2.6/site-packages/django/contrib/auth/models     273    212    77%   23-27, 30, 33, 48, 78, 84, 102, 116-117, 128, 133-138, 144-145, 219, 237-238, 255-260, 265, 268, 328, 331, 336-340, 344-345, 370-371, 373-374, 377-381, 397, 415, 418, 421, 424, 427, 430, 433, 436, 439, 443, 447, 465
Contributor

jbalogh commented Aug 18, 2010

I wouldn't be surprised Django imported contrib stuff before getting to the test runner. There's nothing we can do about that. Does this work for your app code?

Contributor

ipmb commented Aug 19, 2010

We are seeing the same thing for our app code (specifically models.py). Here's an example with an external app:

With django-nose coverage:

$ ./manage.py test --with-coverage --cover-package=mailfriend.models mailfriend
Name                Stmts   Exec  Cover   Missing
-------------------------------------------------
mailfriend.models      16      0     0%   1-20
----------------------------------------------------------------------
Ran 4 tests in 0.173s

With external coverage:

$ coverage -x ./manage.py test mailfriend
$ coverage report --show-missing ../src/django-mailfriend/mailfriend/models.py
Name                                         Stmts   Exec  Cover   Missing
--------------------------------------------------------------------------
../src/django-mailfriend/mailfriend/models      16     15    93%   20
Contributor

carljm commented Aug 19, 2010

I see this same problem, and it is caused by the fix for #19. Which makes perfect sense, given a moment's thought. The whole point of this fix was to make coverage run before django setup, and #19 reverses that.

Contributor

jbalogh commented Aug 19, 2010

nose gives the Capture plugin a score of 500 and the Coverage plugin a score of 300, so Capture always runs before Coverage. I think the only way to get this working would be to bump the Coverage plugin to run before Capture so that it goes Coverage => Django Setup => Capture.

I don't know if there would be side effects from moving the Coverage plugin.

Contributor

carljm commented Aug 19, 2010

That or figure out a way to temporarily disable the effects of the Capture plugin while the Django plugin is running. I haven't really looked at it, but it sure seems like that ought to be possible, without any side-effects outside the Django plugin.

Contributor

rozza commented Aug 25, 2010

This has regressed, I've opened ticket #23 and added a fix for testing there.

Anyone who is coming across this recently, note: If you downloaded django-nose from pypi it has an older version in which #23 was not fixed. Using the source from github will solve your problem

Contributor

jbalogh commented Apr 25, 2011

@evanreiser: the version on pypi should be up to date now. The readme on pypi was lying about the version (my fault) so I thought we had already released this.

Awesome, thank you

@mjtorn mjtorn pushed a commit to mjtorn/django-nose that referenced this issue Jun 11, 2011

@rozza rozza + Jeff Balogh Put setup and teardown of django env into a plugin to allow coverage …
…tracking

Refs #2
29f3092

pbylina commented Jun 17, 2011

I have still the problem.

(internetowykantor)iMac-Pawe-Bylina:development pbylina$ python manage.py test alarm.tests --with-coverage --settings=settings_test --cover-package=alarm --cover-html --cover-html-dir=/tmp/cover --cover-erase --with-doctest --cover-tests

http://pako.overflow.pl/trash/cover_index.html
http://pako.overflow.pl/trash/alarm.models.html

How can i fix it?

Contributor

jbalogh commented Jun 17, 2011

@pbylina What version of django-nose do you have?

pbylina commented Jun 18, 2011

Current version from github.

turian commented Oct 27, 2011

The version on pypi still doesn't fix this for me, I believe this should be reopened.

coverage run manage.py test
also doesn't work for me.

Is this fixed in pypi? I have a fresh install and I'm getting my models.py reported like this

yuriiz commented Dec 20, 2014

Still happens in last PyPi version for me.

vccabral commented Jan 7, 2015

@yuriiz , I am running into the same problem.

with
django-nose==1.3
nose==1.3.4

vccabral commented Jan 7, 2015

@yuriiz I used python's reload module and it fixed my coverage report.

reload('app.models.*')

AusIV commented May 14, 2015

I'm still seeing this issue:

nose==1.3.6
django-nose==1.4
Django==1.8.1

Contributor

jwhitlock commented Jul 3, 2015

This will happen from time to time as Django changes how apps are loaded. See #180 for the current incarnation. Leaving this old bug closed.

I'm trying to get the 'external coverage' workaround working... but when I coverage run manage.py test no .coverage file is output.

If I do coverage run manage.py shell and run some code then I do get the file.

So I assume django-nose (or nose cover plugin) is always overriding the output options for coverage.

If I do coverage run manage.py test --with-coverage then I get the file, but I assume this is the 'internal' django-nose coverage rather than the external one.

sorry, my problem was due to my project's use of libfaketime's reexec_if_needed method https://github.com/simon-weber/python-libfaketime/blob/master/libfaketime/__init__.py ...coverage loses control of the process, code in coverage's try/finally block, where the report is saved, never get to run (!)

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment