为什么coverage.py 不能正确测量Django 的runserver 命令？

Question

我应该知道这个问题的答案，但我不知道：如果您尝试像这样测量 Django 项目的覆盖率：

coverage run manage.py runserver 

您会得到遗漏所有实际代码的覆盖率测量。过程早期的某些事情正在停止测量，或者所有实际工作都发生在一个根本没有被测量的新环境中。

有人可以指出过程中测量失败的特定点，以便我可以尝试修复coverage.py，以便它可以按照人们期望的方式正确测量它吗？

Answer 1

如果你这样运行，你会遇到同样的问题吗？

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%