¿Tiene el mismo problema si ejecuta de la siguiente manera?
coverage run manage.py runserver --noreload
Sin --noreload
, otro proceso se inicia detrás de las escenas. Un proceso ejecuta el servidor, el otro busca cambios de código y reinicia el servidor cuando se realizan cambios. Lo más probable es que esté ejecutando la cobertura en el proceso de supervisión en lugar del proceso de publicación.
Mire django/core/management/commands/runserver.py
y django/utils/autoreload.py
.
Actualización: que ejecutó el comando cobertura, entonces utiliza ps
y lsof
que mirar lo que estaba ocurriendo. Esto es lo que he observado:
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)
OIA, incluso antes de cualquier recarga hay dos procesos, y el que escucha en el puerto TCP no es el que se está ejecutando en la cobertura.
Esto es lo que veo con --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)
así que no es obvio por qué la cobertura no funcionaría en el caso --noreload
. En mi muy breve prueba con --noreload
, tengo la cobertura de mi código de la vista, como se muestra en el siguiente extracto:
festival/__init__ 8 7 13%
manage 9 4 56%
settings 33 1 97%
He actualizado mi respuesta. –