2011-08-13 11 views
18

que debería saber la respuesta a esto, pero no es así: si se intenta medir la cobertura de un proyecto Django así:¿Por qué does not coverage.py mide correctamente el comando runjanver de Django?

coverage run manage.py runserver 

se obtiene la medición de cobertura que pierde todo su código real. Algo al principio del proceso es detener la medición, o todo el trabajo real ocurre en un nuevo contexto que no se mide en absoluto.

¿Alguien me puede indicar el punto específico en el proceso donde se rompe la medición, de modo que puedo tratar de fijar coverage.py para que lo mida adecuadamente de la manera que la gente espera?

+0

He actualizado mi respuesta. –

Respuesta

22

¿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% 
+0

Sí, olvidé mencionar eso en la pregunta: --noreload no cambia el problema. Y estrictamente hablando, la autorrecarga no inicia un nuevo proceso hasta que se vuelve a cargar: al principio, es solo otro hilo que observa cómo los archivos cambian y, si lo hacen, genera otro proceso (creo). –

+0

Gracias por los detalles, la autorecarga siempre ha sido borrosa en mi mente, y has demostrado cómo funciona. Por alguna razón, mis pruebas anteriores demostraron que --noreload no ayudó, pero ahora que lo intento de nuevo, ¡funciona! –

+0

muy bueno! ideal para ejecutar la cobertura en pruebas de integración externa. – stantonk

Cuestiones relacionadas