我应该知道这个问题的答案，但我不知道：如果您尝试像这样测量 Django 项目的覆盖率：
coverage run manage.py runserver
你得到的覆盖率测量错过了你所有的实际代码。过程早期的某些事情是停止测量，或者所有实际工作都发生在一个根本没有被测量的新环境中。
有人可以指出过程中测量失败的特定点，以便我可以尝试修复coverage.py，以便它可以按照人们期望的方式正确测量它？
问问题
2773 次
1 回答
27
如果您按以下方式运行，您会遇到同样的问题吗？
coverage run manage.py runserver --noreload
如果没有--noreload，则在幕后启动另一个过程。一个进程运行服务器，另一个进程查找代码更改并在进行更改时重新启动服务器。很有可能，您正在监视进程而不是服务进程上运行覆盖。
看django/core/management/commands/runserver.py和django/utils/autoreload.py。
更新：我运行了覆盖命令，然后使用ps并lsof查看发生了什么。这是我观察到的：
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，即使在任何重新加载之前也有两个进程，并且侦听 TCP 端口的那个不是正在运行覆盖的那个。
这是我看到的--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)
因此，在这种情况下为什么覆盖面不起作用并不明显--noreload。在我非常简短的测试中--noreload，我得到了我的视图代码的覆盖范围，如下面的摘录所示：
festival/__init__ 8 7 13%
manage 9 4 56%
settings 33 1 97%
于 2011-08-13T15:17:32.917 回答