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。

更新：我运行了coverage命令，然后使用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%

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

1 个答案: