Dlaczego program report.py właściwie nie mierzy komendy runserver Django?

Question

powinienem znać odpowiedź na to pytanie, ale nie: jeśli spróbujesz zmierzyć zasięg projektu Django tak:

coverage run manage.py runserver 

masz pomiar pokrycia że tęskni cały swój rzeczywisty kod. Coś wcześnie w tym procesie zatrzymuje pomiar lub cała prawdziwa praca dzieje się w nowym kontekście, który w ogóle nie jest mierzony.

Czy ktoś może wskazać mi konkretny punkt w procesie, w którym pomiar się psuje, tak, że mogę spróbować naprawić report.py, aby zmierzyć go w sposób zgodny z oczekiwaniami?

Answer 1

Czy ten sam problem występuje, jeśli działasz w następujący sposób?

coverage run manage.py runserver --noreload 

Bez innej konfiguracji rozpoczyna się za kulisami. Jeden proces uruchamia serwer, drugi szuka zmian kodu i restartuje serwer po wprowadzeniu zmian. Istnieje ryzyko, że prowadzisz kontrolę w procesie monitorowania, a nie w procesie udostępniania.

Spójrz na django/core/management/commands/runserver.py i django/utils/autoreload.py.

Aktualizacja: Pobiegłem polecenia pokrycia, a następnie wykorzystywane ps i lsof patrzeć na to co się dzieje. Oto co zauważyłem:

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, nawet przed jakimkolwiek przeładunku istnieją dwa sposoby, a jednym nasłuchuje na porcie TCP nie jest ten, który jest uruchomiony na pokrycie.

Oto co widzę z --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) 

Więc to nie jest oczywiste, dlaczego zasięg nie będzie działać w przypadku --noreload. W bardzo krótkim teście z --noreload otrzymałem informację o moim kodzie podglądu, co pokazuje następujący fragment:

festival/__init__ 8  7 13% 
manage    9  4 56% 
settings   33  1 97%