Лучшие практики для интеграционных тестов с Maven? - PullRequest
Новая
       31

Лучшие практики для интеграционных тестов с Maven?

68 голосов
/ 04 августа 2009

У меня есть проект, который я создаю с помощью Maven, который использует Hibernate (и Spring) для извлечения данных из базы данных и т. Д.

Мои "тесты" для DAO в моем проекте расширяют AbstractTransactionalDataSourceSpringContextTests Spring, так что DataSource может быть подключен к моему тестируемому классу, чтобы иметь возможность фактически выполнять логику запроса / гибернации, извлекать данные и т. Д.

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

Мне любопытно, как лучше организовать эти тесты, которые на самом деле не очень понятны интеграционным тестам, с Maven. Хранить эти тесты в src/test/java кажется немного грязным, но из того, что я прочитал, похоже, нет единой стратегии или практики для организации интеграционных тестов с Maven.

Из того, что я прочитал до сих пор, похоже, что я могу использовать Failsafe плагин (или второй экземпляр Surefire) и связать его с фазой integration-test, и что я также могу связать настраиваемая логика запуска или завершения работы (например, для запуска / остановки экземпляра HSQL) до pre-integration-test или post-integration-test. Но действительно ли это лучший метод?

Так что мой вопрос в основном таков: какова общепринятая лучшая практика при организации этого с Maven? У меня проблемы с поиском какого-либо последовательного ответа в документации.

Я бы хотел:

  • Отдельные модульные тесты от интеграционных тестов, поэтому во время фазы test
  • Возможность привязки пользовательской логики запуска / выключения к pre-integration-test и post-integration-test
  • Объединить / представить отчеты об интеграционных тестах с модульным тестом. Отчеты Surefire

Ответы [ 4 ]

26 голосов
/ 04 июля 2011

Очень простой способ сделать это - использовать категории JUnit.

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

Это занимает минуты и требует всего 3 шага.

  1. Определить интерфейс маркера
  2. Аннотируйте классы, которые вы хотите разделить
  3. Настройка подключаемых модулей Maven.

Полный пример приведен здесь. https://stackoverflow.com/a/10381662/1365383

21 голосов
/ 04 августа 2009

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

Определение интеграционных тестов в src / itest / java На этапе предварительного тестирования:

  • Очистить цель / тестовые классы
  • Используйте цель build-helper-maven-plugin add-test-source, чтобы добавить исходное местоположение
  • Используйте пользовательский Mojo для удаления src / test / java из конфигурации, чтобы модульные тесты больше не компилировались (мне это не очень нравится, но необходимо поддерживать разделение модульных и интеграционных тестов).
  • Используйте компилятор-плагин для компиляции интеграционных тестов

Затем на этапе тестирования интеграции используйте плагин surefire для запуска тестов.

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

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

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

7 голосов
/ 19 июля 2010

Это хорошее сообщение в блоге предлагает три варианта;

1) Отдельный модуль для интеграционных испытаний

2) Различные исходные каталоги

3) Различные шаблоны имен файлов

Мне еще предстоит попробовать все три, так что не могу высказать мнение, которое я поддерживаю.

1 голос
/ 06 сентября 2013

Я предпочитаю второй вариант, «Разные исходные каталоги», но я обнаружил, что довольно раздражает необходимость заканчивать ИТ интеграционными тестами или исключать пакеты.

Чтобы избежать этого, я получил такую ​​конфигурацию: 

<properties>
    <testSource>src/test/java</testSource>
    <testSourceResource>src/test/resources</testSourceResource>
</properties>
<build>
    <testSourceDirectory>${testSource}</testSourceDirectory>
    <testResources>
            <testResource>
            <directory>${testSourceResource}</directory>
            </testResource>
        </testResources>
.....
.....

и затем я переопределяю обе переменные в разных профилях для интеграции и приемочного теста: 

<profiles>
  <profile>
   <id>acceptance-tests</id>
   <properties>
    <testSource>src/acceptance-test/java</testSource>
    <testSourceResource>src/acceptance-test/resources</testSourceResource>
   </properties>
  </profile>
 <profile>
   <id>integration-tests</id>
    <properties>
    <testSource>src/integration-test/java</testSource>
    <testSourceResource>src/integration-test/resources</testSourceResource>
    </properties>
  </profile>
.....
.....
.....
...