а, ну там третий вариант предлагают через локи, но я бы не рекомендовал им пользоваться

да, надо импортнуть LoadScheduling, отнаследоваться от него и переопределить метод schedule

после этого в конфтесте прописать хук



@pytest.mark.trylast
def pytest_xdist_make_scheduler(config, log):
   """ Custom make scheduler """
   dist = config.getoption('dist', default='load')
   schedulers = {
       'load': <Your ingerited scheduler class>,
       'loadscope': LoadScopeScheduling,
       'loadfile': LoadFileScheduling,
   }
   return schedulers[dist](config, log)

решение в лоб - все тесты из этого файла помещать на 1 любой воркер. все остальные тесты - так же как и в оригинале по всем остальным равномерно.

минус решения - 1 воркер у тебя всегда будет статично занят 1 файлом. то есть если там очень мало тестов, то этот воркер закончит свою работу быстрее всех и пока остальные будут потеть - он будет простаивать. если там очень много тестов то наоборот, все воркеры уже закончат работу - а этот будет продолжать пока не добьет свои

и в том и в том случае ты получишь рост времени тестирования

получается не хорошо) так как мне нужно наоборот сократить, а если я в лоб запущу чтобы он в паралель гнал все package, то возможно будут конфликты с тестами например не тот по номеру начнёт прогонятся...

так может лучше избавиться от конфликтов? сделать тесты атомарными и не страдать фигней по распределению?)

Этот вариант у меня был в самом начале 😄но неохота перепиливать было

все что я выше расписал должно делаться только с полными понимаем зачем и в чем плюс такого решения)

и думал сделать некий такой обход

Но чувствую что всё-таки прийдётся перепиливать тесты и спокойно запускать без костылей) Тем не менее спс за помощь) ещё почитаю инфу

есть еще один вариант

к тому что выше, можно добавить логику очередей при распределении. то есть стандартно пайтест берет все тесты, делит их на пачки согласно количестку воркеров и отправляет все пачки тестов на свои воркеры. от этого можно уйти, добавив кретерий максимального количества распределенных тестов. то есть, ставим это значение в 2, и получается что в каждый момент времени на каждом воркере будет находиться 2 теста. 1 в выполнении и 1 следующим в очереди на выполнение.

как только тест выполнится и настанет очередь ожидаемого, планировщик увидит что тестов на воркере стало 1 и докинет новый тест. вот в эту логику можно накидать еще и распределение по файлам.


условно, распределяем тесты, твой файл в реальном времени последовательно распределяем на 1 воркер. как только твой файл закончится - на этот поток докидываем те что остались в общей очереди. это избавит от проблем со временем если время последовательного выполнения тестов из твоего файла меньше чем среднее всех остальных потоков

Привет. Запускаю тест. И мне выдает вот такую ошибку

Error forwarding the new session Empty pool of VM for setup Capabilities {browserName: chrome, browserVersion: latest, platform: WIN10, platformName: windows}
org.openqa.grid.common.exception.GridException: Empty pool of VM for setup Capabilities {browserName: chrome, browserVersion: latest, platform: WIN10, platformName: windows}

может кто знает в чем проблема?

А ты пробовал гуглить?

Да

И как?

Как видишь не очень