Следует ли включать интеграционный тест в непрерывную интеграцию (CI)?

Предположим, что мы разрабатываем веб-приложение, и Хадсон выполняет типичные задачи, такие как компиляция, модульное тестирование и статический анализ кода.

Но сложность заключается в следующем: Hudson развертывает и запускает сервер приложений для выполнения интеграционных тестов после выполнения предыдущих заданий.

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

Как вы думаете, следует ли включать интеграционный тест в продолжение интеграции (CI)? Это может быть вручную? Или упростить интеграционный тест?

Название «Непрерывная интеграция» говорит о многом. Что может быть лучше, чем интеграционное тестирование?
Конечно, это не должно быть единственное место, где проходят эти тесты, когда вы разрабатываете, вы должны постараться убедиться, что вы ничего не сломаете, а не только что ваши изменения работают изолированно.
В конце концов, каждый член команды несет ответственность за то, чтобы все не ломалось, пытаясь обвинить и жестко определить людей или этапы, на которых тестирование ограничено, контрпродуктивно.

Как вы думаете, следует ли включать интеграционный тест в продолжение интеграции (CI)?

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

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

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

Мартин Фаулер говорил о непрерывной доставке как о способе автоматизации всего процесса сборки для быстрого развертывания. Это требует от разработчиков быстрой обратной связи, обеспечиваемой процессом непрерывной интеграции. Поэтому он определяет этапы, которые должна пройти сборка :

1. фиксация сборки
2. тщательное тестирование
3. развертывание

Сборка коммита не должна занимать больше 10 минут, как он заявляет, из-за быстрой обратной связи с разработчиками.

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

Когда это успешно, вы попадаете в часть тестирования интеграции. Здесь вы тестируете взаимодействие только что успешно протестированных модулей. Это включает подачу единиц на вход и отслеживание их состояния / взаимодействия / вывода. Помните, что мы все еще находимся в коммит-билде, поэтому мы хотим, чтобы это тоже было быстро. Поэтому взаимодействия с файловой системой, базой данных, сетевыми одноранговыми узлами и т. П. Должны быть заглушены для быстрого выполнения. Мартин Фаулер также намекает на использование баз данных в памяти, если они вам нужны, просто для быстрого выполнения на сервере CI.

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

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

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