распределенные / более быстрые юнит-тесты Python - PullRequest
4 голосов
/ 01 мая 2009

У меня есть много юнит-тестов Python для проекта, и доходит до того, что их запуск занимает много времени. Я не хочу добавлять больше, потому что я знаю, что они будут делать вещи медленнее. Как люди решают эту проблему? Есть ли простой способ распределить выполнение теста по кластеру?

Ответы [ 5 ]

4 голосов
/ 02 мая 2009

Вы не можете часто запускать все свои тесты, потому что они слишком медленные. Это неизбежное последствие того, что ваш проект станет больше и не исчезнет. Конечно, вы можете запустить тесты параллельно и получить хорошее ускорение, но проблема просто вернется позже, и никогда не будет такой, какой была, когда ваш проект был небольшим.

Для повышения производительности необходимо уметь кодировать, запускать соответствующие модульные тесты и получать результаты в течение нескольких секунд. Если у вас есть иерархия тестов, вы можете сделать это эффективно: запускать тесты для модуля, над которым вы часто работаете, тесты для компонента, над которым вы работаете, время от времени и тесты для всего проекта нечасто (возможно, до подумываю проверить это). У вас могут быть интеграционные тесты или полные системные тесты, которые вы можете запустить в одночасье: эта стратегия является продолжением этой идеи.

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

3 голосов
/ 01 мая 2009

См. Py.test, который имеет возможность передавать модульные тесты группе машин, или Nose, который (для транка, а не текущей версии) поддерживает запуск тестов параллельно с многопроцессорным модулем.

2 голосов
/ 01 мая 2009

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

1 голос
/ 01 мая 2009

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

Тем не менее, рекомендуется выполнить все тесты до того, как вы подтвердите свой код (но сервер непрерывной интеграции может сделать это за вас).

1 голос
/ 01 мая 2009

Первая часть решения этой проблемы - запускать только те тесты, которые необходимы для запуска. Между фиксациями в общей ветке запускаются только те тесты, с которыми взаимодействует новая работа; это должно занять все пять секунд. Если кто-то принимает эту модель, становится жизненно важным выполнить весь набор тестов, прежде чем фиксировать общий ресурс.

Проблема запуска полного набора тестов для целей регрессии, разумеется, остается, хотя она уже частично решена путем простого запуска полного набора реже. Чтобы избежать необходимости ждать, пока выполняется это задание, можно перенести задачу тестирования на другую машину. Это быстро превращается в задачу для системы непрерывной интеграции; buildbot кажется вполне подходящим для вашего варианта использования.

Вы также должны иметь возможность распределять тесты по хостам, используя buildbot, запуская два задания с разными точками входа в набор тестов. Но я не уверен, что это принесет вам большую пользу за первые два шага, которые я здесь упомянул; он должен быть зарезервирован для случаев, когда выполнение тестов занимает гораздо больше времени, чем интервал между фиксациями для общих ресурсов.

D'A

[Предостерегающий лектор: На данный момент мое понимание buildbot в значительной степени теоретическое, и, вероятно, оно сложнее, чем кажется.]

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...