Зачем тестировать в непрерывной интеграции, если вы можете тестировать на pre-commit и pre-push git hooks?
Какой смысл использовать систему непрерывной интеграции для тестирования вашего кода, если у вас уже есть система, подобная Husky, которая позволяет вам тестировать код перед предварительной фиксацией и предварительной загрузкой?
5 ответов
Зажимы pre-commit и pre-push отлично подходят для быстрых операций и тестов. Иногда вы даже можете установить хук в вашей IDE, который будет запускать быстрые модульные тесты каждый раз, когда вы сохраняете файл. Но обычно у вас есть несколько наборов тестов, и, в отличие от функциональных тестов модульных тестов, тесты интеграции и производительности часто выполняются дольше, что невозможно для ловушек.
Кроме того, вы хотите запускать свои тесты в той же среде, в которой вы создаете свои результаты, обычно это не ваша локальная машина.
Другой причиной использования системы CI является запуск тестов после слияния, чтобы убедиться в отсутствии проблем, возникающих при нескольких параллельных слияниях.
В целом, чем больше тестов вы выполняете, тем лучше и система CI позволяет вам запускать как тесты перед слиянием, которые обычно запускаются с помощью какого-либо типа запроса на извлечение запросов и тестов после слияния. И все это в контролируемой надежной среде.
Меня не очень интересует, проходит ли это в вашей локальной среде, где у вас может быть другая версия зависимой библиотеки в вашем пути к среде. Я хочу точно знать, что чей-либо вклад не нарушает программное обеспечение, если оно связано с конкретными версиями библиотеки, с которыми мы поставляем.
Одной из причин тестирования с использованием платформы Continuous Integration, такой как Travis, было бы заверение разработчиков в том, что разработчики не обошли тестирование в своей локальной среде разработки.
CI - это не только тесты, это намного больше, но стадия тестирования, конечно, очень важная часть процесса.
Как вы сказали в своем собственном ответе, локальные среды могут быть изменены, тесты на CI могут иметь более строгие настройки, среда, на которой вы тестируете, может быть больше похожа на среду, которую использует конечный пользователь (скажем, установить версии программного обеспечения или даже аппаратное обеспечение).
Скажем, например, что вы разрабатываете пакет PHP. Пакет имеет поддержку всего между php 5.6 и 7.2, он также должен поддерживать несколько типов операционных систем и должен вести себя по-разному, если ext/open_ssl установлен или нет. Локальный набор тестов редко имел бы установку, позволяющую разработчику тестировать каждую из возможных версий на каждой из требуемых платформ, но набор тестов, настроенный в конвейере CI, мог.
И, честно говоря, это всегда хорошая идея, чтобы проверить еще раз, просто чтобы быть в безопасности!;)
В некоторых полезных и разумных рабочих процессах допустимо фиксировать и отправлять неработающие коммиты (но не в ветку master). Предотвращение таких рабочих процессов с помощью git-хуков раздражает.
Перебазирование или слияние, например, не запускает хуки снова, даже если файлы изменены.
Крючки также очень трудно сделать правильно. Они проверяют локальное состояние, которое может быть не тем, что выдвигается (если присутствуют определенные файлы, которых нет в git).
Серверы CI также обеспечивают стабильную предсказуемую среду. Например, рассмотрим сервер CI с Linux и разработчиков, использующих ноутбуки MacOs. Перехватчики git работают на MacOs, где файловая система нечувствительна к регистру, что позволяет проходить тесты, даже если имена файлов неверны.
Хуки также наказывают прилежных разработчиков, которые перед фиксацией запускают проверки вручную, потому что тесты просто запускаются еще раз.
Каждый профессиональный проект должен иметь CI. Реальный вопрос заключается в том, почему любой проект должен поддерживать раздражающие медленные хрупкие сломанные локальные крючки, когда у вас уже есть CI.
Используйте крючки только для частных проектов игрушек.