Do you get the same problem if you run as follows?
coverage run manage.py runserver --noreload
Without --noreload
, another process is started behind the scenes. One process runs the server, the other looks for code changes and restarts the server when changes are made. The chances are, you're doing the coverage run on the monitoring process rather than the serving process.
Look at django/core/management/commands/runserver.py
and django/utils/autoreload.py
.
Update: I ran the coverage command, then used ps
and lsof
to look at what was happening. Here's what I observed:
ps output:
UID PID PPID C STIME TTY TIME CMD
vinay 12081 2098 0 16:37 pts/0 00:00:00 /home/vinay/.virtualenvs/watfest/bin/python /home/vinay/.virtualenvs/watfest/bin/coverage run manage.py runserver
vinay 12082 12081 2 16:37 pts/0 00:00:01 /home/vinay/.virtualenvs/watfest/bin/python manage.py runserver
lsof output:
python 12082 vinay 5u IPv4 48294 0t0 TCP localhost:8000 (LISTEN)
IOW, even before any reloading there are two processes, and the one listening on the TCP port is not the one which coverage is running on.
Here's what I see with --noreload
:
ps output:
UID PID PPID C STIME TTY TIME CMD
vinay 12140 2098 5 16:44 pts/0 00:00:00 /home/vinay/.virtualenvs/watfest/bin/python /home/vinay/.virtualenvs/watfest/bin/coverage run manage.py runserver --noreload
lsof output:
coverage 12140 vinay 4u IPv4 51995 0t0 TCP localhost:8000 (LISTEN)
So it's not obvious why coverage wouldn't work in the --noreload
case. In my very brief test with --noreload
, I got coverage of my view code, as shown by the following extract:
festival/__init__ 8 7 13%
manage 9 4 56%
settings 33 1 97%
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…