我应该知道这个问题的答案,但我不知道:如果您尝试像这样衡量 Django 项目的覆盖率:
coverage run manage.py runserver
您会得到遗漏所有实际代码的覆盖率测量。过程早期的某些事情正在停止测量,或者所有实际工作都发生在一个根本没有被测量的新环境中。
有人可以指出过程中测量失败的特定点,以便我可以尝试修复coverage.py,以便它可以按照人们期望的方式正确测量它吗?
最佳答案
如果你这样运行,你会遇到同样的问题吗?
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
的非常简短的测试中,我得到了我的 View 代码的覆盖范围,如下面的摘录所示:
festival/__init__ 8 7 13%
manage 9 4 56%
settings 33 1 97%
关于python - 为什么coverage.py 不能正确测量Django 的runserver 命令?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7051070/