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

[jbalogh]

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

[davedash]

Looks like you fixed this?

[jbalogh]

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.

[rozza]

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

[carljm]

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

[jbalogh]

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]

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

Is a new release planned?

[jbalogh]

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.

[ipmb]

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

[jbalogh]

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?

[ipmb]

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

[carljm]

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.

[jbalogh]

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.

[carljm]

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.

[rozza]

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

[evanreiser]

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

[jbalogh]

@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.

[evanreiser]

Awesome, thank you

[pbylina]

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?

[jbalogh]

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

[pbylina]

Current version from github.

[turian]

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.

[AdrianLC]

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

[yuriiz]

Still happens in last PyPi version for me.

[vccabral]

@yuriiz , I am running into the same problem.

with
django-nose==1.3
nose==1.3.4

[vccabral]

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

reload('app.models.*')

[AusIV]

I'm still seeing this issue:

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

[jwhitlock]

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.

[anentropic]

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.

[anentropic]

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 (!)