Używam coveralls w połączeniu z coverage.py do śledzenia kodu Pythona dla moich skryptów testowych. Używam następujące polecenia:Zakres kodu Pythona i wieloprocesorowość
coverage run --parallel-mode --source=mysource --omit=*/stuff/idont/need.py ./mysource/tests/run_all_tests.py
coverage combine
coveralls --verbose
Działa to całkiem ładnie z wyjątkiem multiprocessing. Kod wykonywany przez pule procesów lub procesy potomne nie jest śledzony.
Czy istnieje możliwość śledzenia kodu wieloprocesorowego? Jakieś szczególne opcje, których mi brakuje? Może dodając opakowania do biblioteki wieloprocesowej, aby rozpocząć pokrycie za każdym razem, gdy nowy proces zostanie zainicjowany?
EDIT:
I (i jonrsharpe również :-) znalazł monkey-patch for multiprocessing.
Jednak to nie działa dla mnie, mój build Tracis-CI ginie niemal natychmiast po starcie. Sprawdziłem problem na mojej lokalnej maszynie i najwyraźniej dodanie łaty do wieloprocesorowego popsucia pamięci. Testy, które zajmują znacznie mniej niż 1 GB pamięci, wymagają ponad 16 GB tej poprawki.
EDIT2:
Małpa-plaster działa po niewielkiej modyfikacji: Usuwanie config_file dekodowaniu (config_file=os.environ['COVERAGE_PROCESS_START']) wystarczyły. To rozwiązało problem nadętej pamięci. W związku z powyższym, odpowiednia linia staje się po prostu:
cov = coverage(data_suffix=True)
Czy nie przetestować kod dla tych procesów potomnych bezpośrednio? – jonrsharpe
Cóż, tak, większość z nich robię. Ale są pewne części, które są użyteczne i są wykonywane tylko w przypadku użycia procesu wieloprocesowego (jak zawijanie dostępu do bazy danych z blokadami lub kolejka do przetwarzania wieloprocesowego w celu wymuszenia przechowywania danych szeregowych). I wiem, że ten kod działa dzięki pomyślnym testom. Byłoby miło, gdyby pojawiło się również na kombinezonach :-) – SmCaterpillar
Zobacz https://bitbucket.org/ned/coveragepy/issue/117/enable-coverage-measurement-of-code-run-by, przez http : //nedbatchelder.com/code/coverage/trouble.html – jonrsharpe