dmakhno
(Dmytro Makhno)
04.Апрель.2014 10:35:41
#1
Разбираюсь с возможностями распараллеливания в Питоне.
run_log
$ nosetests --processes 5 test_debug_parallel.py
INFO - heavy operation is beginning... 1 FirstTest
INFO - heavy operation is beginning... 1 SecondTest
INFO - heavy operation is beginning... 1 ThirdTest
INFO - heavy operation has ended 1 FirstTest
DEBUG - 47620 140735328031504 1396607234.95 setUpClass 1 FirstTest
INFO - heavy operation has ended 1 SecondTest
DEBUG - 47621 140735328031504 1396607234.96 setUpClass 1 SecondTest
INFO - heavy operation has ended 1 ThirdTest
DEBUG - 47622 140735328031504 1396607234.98 setUpClass 1 ThirdTest
This file has been truncated. show original
test_parallel.py
# Try with:
# nosetests --processes 5 test_debug_parallel.py -- setUpClass called once per suite,
# same behaviour as SHARE=False or SPLIT=False
# SHARE=True nosetests --processes 5 test_debug_parallel.py -- setUpClass called once for all inheritors
# SPLIT=True nosetests --processes 5 test_debug_parallel.py -- many-many setUpClass
# py.test -s -n 5 test_parallel.py -- same as nose _multiprocess_can_split_=True
# Requirements:
# python_2.7
# py.test
This file has been truncated. show original
(Надеюсь кому-то пригодится. Возможно вы видете устаревший гист, лучше на него “тыцнуть”)
Из коробки, очень нравится как делает nose. Где setUpClass вызывается для каждого тест сьюта один раз. Но, субъективно, интеграция py.test с xunit => jenkins, дает более понятное описание проблемы, если пошло что-то не так.
Может кто знает как достичь подобного распараллеливания с помощью py.test?
Готов попробовать другие варианты.
Note: Природа продукта такова, что сами тесты “легкие”, но подготовка класса очень трудоемкая задача. Нет возможности замокать подготовку или сделать in-memory. Некоторые тесты подымают 1-3 виртуальные машины в амазоне и это необходимость.
P.S. “А есть такое только без крыльев?.. Будем искать” (c)
2 лайка
polusok
(Mykhailo Poliarush)
07.Апрель.2014 10:06:06
#2
насколько я увидел из кода
то можно сделать это через hook а не через setupClass
посмотри вот эти хуки насколько они часто вызываются
def pytest_configure(config):
if not hasattr(config, 'slaveinput'):
pass
def pytest_sessionstart(session):
pass
как будет время, выдам работающий код, пока что экспериментируй самостоятельно
polusok
(Mykhailo Poliarush)
11.Апрель.2014 18:41:15
#3
@dmakhno ну что удалось решить проблему?
dmakhno
(Dmytro Makhno)
11.Апрель.2014 19:06:29
#4
Миша,
Пока не добрался, пришлось переклються на другую задачу. Думаю вот на выходных разберусь. Заодно py.test по докам и сорцам детальнее пробегу.
Пока не взял ноут ‘имперически’ оживляю тред
https://bitbucket.org/hpk42/pytest/issue/175/way-to-control-how-pytest-xdist-runs-tests
polusok
(Mykhailo Poliarush)
16.Апрель.2014 05:16:48
#5
и это самый правильный способ, можно конечно и свои костыли писать, но вернее убедить разработчика pytest в нужности функции и тогда он сделает в 100% правильнее
если бы там был лайк, я бы поставил
polusok
(Mykhailo Poliarush)
16.Апрель.2014 13:16:07
#7
Точно! Я просто не был залогинен и голосовать нельзя было
polusok
(Mykhailo Poliarush)
25.Декабрь.2014 18:53:50
#8
Сделал небольшой костыль по этому поводу. Указан в другой теме
В общем, выделил немного времени на то чтобы посмотреть воркараунд, заодно и добавлю практический пример для урока по юнит тестированию http://lessons2.ru/lesson/preview/yunit-testirovanie-v-python/ .
Заключение, просто это сделать не получиться (может быть и можно как-то, но надо больше времени на эксперименты)
Это больше быстрый костыль нежели решение, но все же лучше иметь что-то чем ничего.
Есть одно ограничение, из-за того что xdist плагин использует execnet модуль для сериализации, в нем реализовано сериализация только примитивных типов и к сожалению экземпляры объектов не могут быть сериализированны. Т.е. нельзя напрямую присвоить экземпляр класса для нового созданного no…