Что Саша О сказал действительно важно. Если ваша сборка занимает столько времени, возможно, ваши тесты - это не простые юнит тесты. Так что разделение тестов на две категории будет хорошей идеей. Ваши быстрые тесты должны быть реальными модульными тестами, что означает, что они не должны включать контекст Spring, важные операции ввода-вывода или реального соединения с базой данных (вы можете использовать базу данных в памяти, такую как H2 или HSQLDB).
Если вы используете TestNG для своих тестов, вы можете использовать функцию групп для разделения ваших тестов. Если вы используете JUnit , @Category
может быть полезным. Используя JUnit, этот @Category
не идеален, и для меня это была проблема . Я решаю свою проблему путем создания собственного JUnit Runner (решение не является идеальным, но может быть полезным).
Еще один совет: возможно, вы могли бы подумать об использовании более качественного оборудования для сервера непрерывной интеграции. Действительно, компиляция и выполнение тестов могут быть действительно улучшены с помощью компьютера с лучшими характеристиками. Также, если вы не используете последний JDK, вы можете перейти на JDK 1.6, например ...
Наконец, есть интересный вариант с Maven начиная с версии 2.1: инкрементная сборка . Эта опция доступна, когда вы нажимаете кнопку «Дополнительно» параметров сборки Maven, если вы используете Hudson / Jenkins.
Принцип состоит в том, чтобы создавать только те модули, на которые влияют ваши изменения (т. Е. Коммиты). Давайте возьмем пример. У меня есть этот проект:
project
+- commons
+- persistence
+- business
Проект business
зависит от persistence
, что зависит от commons
. Теперь, если у вас есть коммит в проекте persistence
, зачем вам нужно компилировать, тестировать и паковать commons
, так как этот проект не изменился? Опция incremental build
будет перестраивать только измененный проект, а также зависимые модули. В моем примере будет восстановлено persistence
, а также business
.