Ответ 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%