Как сохранить автоматизированные тесты быстро?

Question

Автоматизированные тесты ДОЛЖНЫ быть быстрыми, чтобы отражать состояние проекта в реальном времени. Идея в том, что:

1. после выполнения автоматической фиксации в репозитории (настолько быстро, насколько это возможно).
2. если сборка прошла успешно, запускаются автоматические тесты. ДОЛЖЕН быть быстрым.

Это лучший способ узнать, не нарушают ли ваши изменения что-либо.

Сначала казалось, что быстрое построение сложно, но нам удалось сохранить его примерно на 100 секунд. для решения 105 (!) проектов (MSVS 2008 C #).

Тесты оказались не такими простыми (мы используем NUnit FW). Модульное тестирование не является большой проблемой. Это интеграционные тесты, которые убивают нас. И не факт, что они медленнее (любые идеи о том, как сделать их быстрее, высоко ценится), а не факт, что должна быть настроена среда, которая НАМНОГО медленнее (атм ~ 1000 сек)!

В наших интеграционных тестах используются службы web / win (на данный момент 19), которые необходимо перераспределить для отражения последних изменений. Это включает в себя перезапуск служб и большое количество операций с жесткими дисками.

Может ли кто-нибудь поделиться опытом о том, как / можно организовать / оптимизировать среду и рабочий процесс для ускорения фазы автоматизированного тестирования. Каковы узкие места и обходные пути «низкого уровня».

P.S. книги и широкие статьи приветствуются, но реальные рабочие решения гораздо ценнее.

Answer 1

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

Некоторые тесты требуют времени. Это факт жизни. Интеграционные тесты обычно занимают время, и вам, как правило, приходится настраивать среду, чтобы их можно было выполнить. Если вы настроите среду, вы захотите иметь среду, максимально приближенную к конечной производственной среде.

У вас есть два варианта:

1. Оптимизация тестов или развертывание тестов.
2. Не делай их так часто.

По моему опыту, лучше иметь правильную среду интеграции, которая находит ошибки и адекватно представляет конечную среду производства. Я обычно выбираю вариант 2 (1).

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

(1) За исключением случаев, когда есть множество ошибок, которые обнаруживаются только в интеграции, в этом случае забудьте все, что я сказал: -)

Answer 2

Мы используем .NET и NUnit, которые поддерживают категории (атрибут, который вы можете поставить на тест). Затем мы проводим длительные тесты и помещаем их в категорию NightlyCategory, чтобы они запускались только во время ночных сборок, а не в непрерывных сборках, которые мы хотим выполнить быстро.

Answer 3

Лучшее решение для этой ситуации - создать резервную копию изображений-образов среды и восстановить образ перед сбросом среды. Это будет иметь больше смысла к потраченному времени.

Answer 4

тот факт, что среда должна быть установка, которая НАМНОГО медленнее (атм ~ 1000 сек)!

Ну, по крайней мере, вы знаете, на чем сосредоточиться ... Знаете ли вы, где проводится это время?

Очевидно, что любое решение будет зависеть от специфики здесь.

В такой ситуации я использовал три решения:

1. использовать больше машин. Возможно, вы могли бы разделить свои сервисы на две машины? Позволит ли это вам сократить время настройки в 1/2?

2. использовать более быстрые машины? В одной ситуации, которую я знаю в команде, было сокращено тестирование интеграции с 18 часов до 1 часа путем обновления аппаратного обеспечения (несколько процессоров, быстрое хранилище RAID, больше оперативной памяти, все работает). Конечно, это стоило им порядка 10 тысяч долларов, но оно того стоило.

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

Answer 5

Я бы посоветовал провести несколько высокоуровневых тестов, и если какой-либо из них не пройдёт, запустите тесты с «более высоким разрешением».

Подумайте о технической поддержке по телефону ...

работает ли ваш компьютер? если да, то сделано. Если нет, ваш компьютер вообще включается? ...

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

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

Этот подход дает мне скорость и детализацию.

Answer 6

Я собрал презентацию о Turbo-Charged Test Suite . Вторая половина предназначена для разработчиков Perl, но первая половина может оказаться полезной для вас. Я не знаю достаточно о вашем программном обеспечении, чтобы понять, подходит ли оно.

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

Answer 7

Buildbot: http://buildbot.net/trac Я не могу рекомендовать это достаточно, если вы делаете непрерывную интеграцию (автоматическое тестирование). При быстрой настройке все наши модульные тесты запускаются каждый раз, когда происходит фиксация, а более длительные интеграционные тесты запускаются периодически в течение дня (3 раза в последний раз, когда я проверял, но это легко изменить).