Ночные сборки против непрерывной интеграции: долгосрочные автоматизированные тесты

У нас есть "проблема" большого автоматизированного набора интеграционных тестов. Хотя время сборки разумно (< 1 час), тесты обычно занимают более 6 часов.

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

Я рассмотрел темы обсуждения, такие как этот, которые подробно описывают различия.

Это приводит меня к нескольким вопросам:

Является ли CI диктовать или рекомендовать автоматизацию тестирования подразделения или интеграции? Я слышал Unit-only только в прошлом, но я не нахожу таких утверждений (или обоснований) для этого в ходе быстрого поиска.
Какая хорошая "передовая практика" для комбинированной сборки + автоматизированных тестовых времен/коэффициентов для эффективного CI для команды? Моя кишка говорит мне, что это должно быть < 2 часа в худшем случае и, вероятно, 1 час, чтобы быть действительно эффективным. Теоретически, мы могли бы разбить тесты на параллельную работу и, вероятно, заставить их работать менее чем за 2 часа, но это будет продолжаться 3 часа.
Каков наилучший путь вперед от долговременных тестов Nightly Builds + Integration Tests к CI? Я думаю о создании CI с несколькими скелетными модульными тестами только в сочетании с ночными сборками, которые продолжаются с интеграционными тестами.

Любые рекомендации по инструментам также приветствуются (Windows-only С#/С++ codebase)

Ответ 1

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

Источник: http://martinfowler.com/articles/continuousIntegration.html#KeepTheBuildFast

Почему требуется 6 часов? Сколько у вас тестов? Каково отношение единицы измерения к интегрированным? У вас, вероятно, есть еще много интегрированных тестов, или ваш блок-тест на самом деле не является единицей. Являются ли ваши тесты устройств касающимися БД? Это может быть проблемой.

6 часов - долгое время. В приведенной выше статье есть несколько советов.

Ответ 2

Здесь есть несколько вещей.

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

Вам определенно не нужна ни одна сборка, которая делает все.

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

6 часов также очень долгое время. вы уверены, что ваши тесты проверяют правильные вещи? у вас слишком много широких исследований? вы используете "sleep()" повсюду в макияже за то, что вы не смоделировали асинхронность в своем тестовом коде?

Вероятно, вам стоит взять книгу Джеза Хэмблса "Непрерывная доставка" и взглянуть на Growing Object Oriented Software на то, как писать тесты на единицу/интеграцию. GOOS использует Java как язык реализации, но все понятия одинаковы.