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

Question

У нас есть «проблема» большого автоматизированного набора интеграционных тестов. Несмотря на то, что время сборки приемлемое (<1 час), тестирование обычно занимает> 6 часов.

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

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

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

1. Дает ли CI указание или рекомендует автоматизацию тестирования Unit против Integration? В прошлом я слышал «Только для юнитов», но не нашел таких заявлений (или обоснований) для этого в быстром поиске.

2. Что такое хорошая "лучшая практика" для комбинированных сборок + времени / коэффициентов автоматического тестирования, чтобы иметь эффективный КИ для команды? Моя интуиция говорит мне, что это должно быть <2 часа в худшем случае и, вероятно, <1 час, чтобы быть действительно эффективным. Теоретически мы можем разбить тесты на параллельные и, возможно, запустить их менее чем за 2 часа, но это все равно будет 3 часа. </p>

3. Как лучше всего перейти от длительных тестов Nightly Build + Integration к CI? Я имею в виду сборку CI только с несколькими скелетными юнит-тестами в сочетании с ночными сборками, которые продолжаются интеграционными тестами.

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

Answer 1

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

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

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

6 часов - это время long .В статье выше есть несколько советов.

Answer 2

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

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

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

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

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

Вероятно, вам следует взять книгу Джеза Хамблса «Непрерывная доставка» иПосмотрите на растущее объектно-ориентированное программное обеспечение, как писать модульные / интеграционные тесты.GOOS использует Java в качестве языка реализации, но все концепции одинаковы.