Нужно ли запускать тесты на CI-сервере, если каждый разработчик запускает тесты перед push? - PullRequest
0 голосов
/ 06 июля 2018

Я не уверен, что лучше всего использовать юнит-тесты.

Я полагаю, что каждый разработчик должен пройти модульные тесты локально, прежде чем отправлять код в репозиторий GIT. И тогда CI-сервер (Jenkins) обнаружит новые изменения и снова запустит тесты. Почему мы хотим сделать это дважды? Должны ли мы?

Если модульные тесты занимают много времени, ожидаем ли мы, что разработчик выбирает только те тесты, которые связаны с изменением, или запускает все тесты (даже вне рамок своих проектов), предполагая, что у нас много модуль ПОМ.

Также учтите, что у нас обычно есть мощное оборудование для CI-сервера и относительно менее мощная рабочая станция для разработчиков.

Ответы [ 2 ]

0 голосов
/ 06 июля 2018

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

Поскольку разработчик изменяет класс, изменяет структуру базы данных или вносит любые изменения, которые могут иметь побочные эффекты, он / она не будет / не сможет знать все потенциальные побочные эффекты для всего приложения.
И он / она никогда не должен пытаться быть слишком умным, говоря: «Я знаю, что это могло быть нарушено моими изменениями, поэтому я проведу только этот тест».

Модульное тестирование обеспечивает некоторую степень качества кода: не делайте его менее полезным

Юнит-тесты также являются нерегрессионными. Чтобы не воспроизводить все нерегрессионные тесты до коммита и push, существует риск внедрения некорректного кода в управление исходным контентом.
Ты никогда этого не сделаешь.

Модульные тесты должны выполняться быстро

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

CI должен выполнить все тесты

Нужно ли запускать тесты на CI-сервере, если каждый разработчик запускает тесты? перед толчком?

Как объяснено, интеграционные тесты должны выполняться инструментом CI.
Что касается модульного тестирования, то щадить его выполнение на стороне CI тоже не очень хорошая идея.
Конечно, разработчики должны запускать тесты перед отправкой в ​​SCM, но на самом деле у вас нет гарантии, что это будет всегда.
Кроме того, даже в идеальном мире, где разработчики выполняют все тесты до нажатия, вы можете попасть в случаи, когда тесты пройдут успешно на компьютере разработчика, но не пройдут на CI или других машинах разработчика.
Например, разработчик может ввести в базовый код некоторые абсолютные пути, характерные для его компьютера, или он / она также может забыть реплицировать модификацию базы данных, используемой в среде CI.
Поэтому запуск всех тестов (модульных и интеграционных тестов) не должен быть опцией для CI.

0 голосов
/ 06 июля 2018

Да, они должны быть запущены дважды. Потому что, если некоторые разработчики этого не делают, они никогда не работают Разработчики должны запускать тесты локально, чтобы убедиться, что их код работает правильно.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...