Хадсон CI - функциональные или модульные тесты?

Question

У меня есть Хадсон, опрашивающий многочисленные проекты каждые 5 минут и запускающий проверки компиляции.Они состоят из сборок ant для java-проектов и внедряются в справочную базу данных для кода базы данных, и система работает хорошо.

Теперь я нахожусь на распутье.У меня уже есть обширный набор функциональных тестовых примеров, которые используют многие компоненты.Под функционалом я подразумеваю, что они в основном имитируют то, что делал бы наш ручной отдел контроля качества.Тесты черного ящика, если хотите.Это тестовые наборы JUnit, но они не являются тестовыми.Мне интересно, подходит ли этот класс теста для 5-минутного опроса или вместо этого я должен использовать больше тестовых случаев типа «белый ящик».Может быть, функциональные комплекты должны быть частью ночной сборки?

Любые мнения оценили Петр

Answer 1

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

Это не значит, что вам нужно опросить оба проекта. Что мы сделали, так это разбили его на несколько разных заданий Хадсон / Дженкинс:

• Одна работа опрашивает SCM, компилирует и развертывает проект (довольно быстро, ~ несколько минут)
• Когда это задание заканчивается, оно автоматически запускает второе задание, которое запускает большинство функциональных тестов (5-20 минут, в зависимости от проекта)
• Третье задание выполняется каждую ночь, и проводится еще более обширное тестирование с тестами, которые требуют много времени для запуска или связывания большого количества ресурсов (занимает ~ несколько часов)

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

Answer 2

То, что мы делали на моем предыдущем рабочем месте: задача Ant для сборки в Hudson включала в себя модульное тестирование, поэтому, если какой-либо модульный тест не удался, задача сборки не выполнялась.За этим последовал сценарий установки пакета на сервер функционального тестирования, за которым последовали примеры функционального тестирования.В случае настольного приложения тестовые примеры Squish выполнялись после ночных сборок.В EE-приложении у нас был настоящий CI, там у нас были тестовые наборы Cucumber / Selenium, также развернутые с помощью задач Ant.

Правило было простым: запускать каждую задачу Ant на своем компьютере и фиксировать изменения кода только один разкаждый контрольный пример имеет зеленый цвет.

В другой компании я видел следующую политику: если вы нарушаете задание сборки Hudson и не исправляете его в течение часа, ваш коммит возвращается назад.

Answer 3

Являются ли эти тесты в целом хрупкими или они достаточно стабильны?

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

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

Answer 4

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

Однако, если тесты являются интеграционными тестами, я действительно думаю, что вам следует подумать, не будет ли более полезным переписать эти тесты в unittest (со временем). Мое любимое чтение по этой теме: Интегрированные тесты - это афера .

Кроме этого я делаю второй ответ @ Laepdjek.