ТЛ; др
Никогда не делайте тестовые пропуски обычным явлением в вашей сборке.
Регулярное выполнение - это порочный круг, который сделает ваши тесты бесполезными, а ваше приложение менее надежным.
Длинная версия
Автоматическая сборка из IDE (Eclipse или любой другой)
Среды IDE, позволяющие использовать Maven в качестве инструмента сборки, не выполняют модульные тесты при каждой сборке, поскольку по умолчанию они не выполняют ни цель test, ни цель package. Вместо этого они фокусируются на плагине компилятора (compile и test-compile), а также на плагине ресурсов (resources и test-resources).
Поэтому модульные тесты не должны выполняться при каждой автоматической сборке, выполняемой вашей IDE.
Сборка с пакетом mvn / установка
Почему я должен (не) пропустить тесты во время сборки?
Ваш вопрос относится к Maven, но это может быть любой другой инструмент сборки или любой язык программирования, и он будет иметь такие же последствия.
Сначала задайте вопрос, почему мы пишем модульные тесты.
Мы пишем их , чтобы проверить поведение наших компонентов , а также , чтобы их предупреждали, поскольку поведение наших компонентов больше не ведет себя должным образом (обнаружение регрессии) .
Регулярное игнорирование выполнения тестов означает, что вы рискуете, чтобы ваши компоненты модульных тестов имели регрессию в своем поведении, не зная о них.
И позже могут возникнуть другие регрессии, и вы все равно не будете знать о них.
И намного позже многие из ваших тестов не пройдут, так как вы никогда не исправляете их, чтобы соответствовать ожидаемому поведению.
Поскольку сбой теста препятствует сборке, очень вероятно, что вы пропустите / отключите / прокомментируете / удалите модульные тесты, потому что они не проходят слишком часто и в слишком многих случаях.
Ваши юнит-тесты превратятся в пыль, и вы потеряете все преимущества, предоставляемые юнит-тестами.
Но почему существует опция пропуска тестов?
Я рекомендую / использую их только для угловых случаев , таких как следующие (не исчерпывающие) и только временно :
устаревшие проекты, многие тесты которых не поддерживались.
Так как их исправление займет слишком много времени, в первый раз у вас нет других вариантов, которые могли бы пропустить их при создании компонента.
И как можно скорее вы должны отключить ненадежные тесты (@Ignore с JUnit), исправить их или запланировать. Таким образом, вы можете снова включить выполнение тестов и позволить регулярно выполнять рабочие тесты.
проекты, в которых тесты могут завершиться неудачей в зависимости от среды выполнения.
Здесь опять-таки это должен быть временный обходной путь и он тоже изолирован.
Действительно, как можно скорее вы должны найти способ сделать тесты успешными независимо от среды, в которой они выполняются.