it-roy-ru.com

Как настроить JPA для тестирования в Maven

Есть ли способ настроить второй файл persistence.xml в проекте Maven, чтобы он использовался для тестирования вместо обычного, используемого для развертывания?

Я попытался поместить файл persistence.xml в src/test/resources/META-INF, который копируется в target/test-classes/META-INF, но кажется, что target/classes/META-INF (копия из src/main/resources) становится предпочтительным, несмотря на то, что mvn -X test перечисляет записи пути к классам в правильном порядке:

[DEBUG] Test Classpath :
[DEBUG]   /home/uqpbecke/dev/NetBeansProjects/UserManager/target/test-classes
[DEBUG]   /home/uqpbecke/dev/NetBeansProjects/UserManager/target/classes
[DEBUG]   /home/uqpbecke/.m2/repository/junit/junit/4.5/junit-4.5.jar
...

Я хотел бы иметь возможность запускать тесты для простой конфигурации hsqldb без необходимости изменения версии развертывания конфигурации JPA, в идеале сразу после проверки проекта без необходимости локальной настройки.

65
Peter Becker

Следующее будет работать для Maven 2.1+ (до этого между тестом и пакетом не было фазы, с которой вы могли бы связать выполнение).

Вы можете использовать maven-antrun-plugin для замены файла persistence.xml тестовой версией на время тестов, а затем восстановить правильную версию перед упаковкой проекта.

В этом примере предполагается, что производственная версия - src/main/resources/META-INF/persistence.xml, а тестовая версия - src/test/resources/META-INF/persistence.xml, поэтому они будут скопированы в target/classes/META -INF и target/test-classes/META-INF соответственно.

Было бы более элегантно инкапсулировать это в mojo, но поскольку вы только копируете файл, это кажется излишним.

<plugin>
  <artifactId>maven-antrun-plugin</artifactId>
  <version>1.3</version>
  <executions>
    <execution>
      <id>copy-test-persistence</id>
      <phase>process-test-resources</phase>
      <configuration>
        <tasks>
          <!--backup the "proper" persistence.xml-->
          <copy file="${project.build.outputDirectory}/META-INF/persistence.xml" tofile="${project.build.outputDirectory}/META-INF/persistence.xml.proper"/>
          <!--replace the "proper" persistence.xml with the "test" version-->
          <copy file="${project.build.testOutputDirectory}/META-INF/persistence.xml" tofile="${project.build.outputDirectory}/META-INF/persistence.xml"/>
        </tasks>
      </configuration>
      <goals>
        <goal>run</goal>
      </goals>
    </execution>
    <execution>
      <id>restore-persistence</id>
      <phase>prepare-package</phase>
      <configuration>
        <tasks>
          <!--restore the "proper" persistence.xml-->
          <copy file="${project.build.outputDirectory}/META-INF/persistence.xml.proper" tofile="${project.build.outputDirectory}/META-INF/persistence.xml"/>
        </tasks>
      </configuration>
      <goals>
        <goal>run</goal>
      </goals>
    </execution>
  </executions>
</plugin>
26
Rich Seller

В проекте EE6/CDI/JPA тестовый src/test/resources/META-INF/persistence.xml подобрался просто без дополнительной настройки.

При использовании JPA в Spring в контексте приложения, используемого для тестирования, работает следующее:

<bean id="entityManagerFactory"
    class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="dataSource" ref="dataSource" />
    <!--
        JPA requires META-INF/persistence.xml, but somehow prefers the one
        in classes/META-INF over the one in test-classes/META-INF. Spring
        to the rescue, as it allows for setting things differently, like by
        referring to "classpath:persistence-TEST.xml". Or, simply referring
        to "META-INF/persistence.xml" makes JPA use the test version too: 
    -->
    <property name="persistenceXmlLocation" value="META-INF/persistence.xml" />

    <!-- As defined in /src/test/resources/META-INF/persistence.xml -->
    <property name="persistenceUnitName" value="myTestPersistenceUnit" />
    <property name="jpaVendorAdapter">
        <bean
            class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
        </bean>
    </property>
</bean>

Здесь /src/test/resources/META-INF/persistence.xml (скопированный в target/test-classes) предпочтительнее /src/main/resources/META-INF/persistence.xml (скопированный в target/classes).

К сожалению, местоположение файла persistence.xml также определяет так называемый « persistence unit's root », который затем определяет, какие классы сканируются для аннотаций @Entity. Таким образом, использование /src/test/resources/META-INF/persistence.xml будет сканировать классы в target/test-classes, а не классы в target/classes (где будут жить классы, которые необходимо протестировать). 

Следовательно, для тестирования нужно было бы явно добавить записи <class> в persistence.xml, чтобы избежать Java.lang.IllegalArgumentException: Not an entity: class .... Потребности в записях <class> можно избежать, используя другое имя файла, например persistence-TEST.xml, и поместите этот файл в ту же папку, что и обычный файл persistence.xml. Тогда контекст Spring из вашей тестовой папки может просто ссылаться на <property name="persistenceXmlLocation" value="META-INF/persistence-TEST.xml" />, и Spring найдет его для вас в src/main.

В качестве альтернативы можно сохранить persistence.xml одинаковым для реального приложения и тестов и определить только один в src/main. Вместо этого большинство настроек, таких как драйверы, диалект и дополнительные учетные данные, можно выполнить в контексте Spring. Также настройки, такие как hibernate.hbm2ddl.auto, могут быть переданы в контексте :

<bean id="dataSource"
    class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    <!-- For example: com.mysql.jdbc.Driver or org.h2.Driver -->
    <property name="driverClassName" value="#{myConfig['db.driver']}" />
    <!-- For example: jdbc:mysql://localhost:3306/myDbName or 
        jdbc:h2:mem:test;DB_CLOSE_DELAY=-1 -->
    <property name="url" value="#{myConfig['db.url']}" />
    <!-- Ignored for H2 -->
    <property name="username" value="#{myConfig['db.username']}" />
    <property name="password" value="#{myConfig['db.password']}" />
</bean>

<bean id="jpaAdaptor"
    class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
    <!-- For example: org.hibernate.dialect.MySQL5Dialect or 
        org.hibernate.dialect.H2Dialect -->
    <property name="databasePlatform" value="#{myConfig['db.dialect']}" />
</bean>

<bean id="entityManagerFactory"
    class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="dataSource" ref="dataSource" />
    <property name="jpaVendorAdapter" ref="jpaAdapter" />
    <property name="jpaProperties">
        <props>
            <!-- For example: validate, update, create or create-drop -->
            <prop key="hibernate.hbm2ddl.auto">#{myConfig['db.ddl']}</prop>
            <prop key="hibernate.show_sql">#{myConfig['db.showSql']}</prop>
            <prop key="hibernate.format_sql">true</prop>
        </props>
    </property>
</bean>
20
Arjan

Кажется, несколько файлов persistence.xml - это общая проблема с JPA, решаемая только хитростями загрузки классов.

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

13
Peter Becker

Добавьте persistance.xml для тестов: /src/test/resources/META-INF/persistence.xml Как сказал @Arjan, это изменит корень модуля персистентности , а классы сущностей будут сканироваться в target/test-classes. Для этого добавьте элемент jar-file в этот файл persistance.xml:

/src/test/resources/META-INF/persistence.xml

<persistence xmlns="http://Java.Sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://Java.Sun.com/xml/ns/persistence http://Java.Sun.com/xml/ns/persistence/persistence_2_0.xsd"
             version="2.0">
    <persistence-unit name="com.some.project">
        <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
        <jar-file>${project.basedir}/target/classes</jar-file>
        <properties>
            <property name="javax.persistence.jdbc.url" value="jdbc:postgresql://localhost:5432/test_database" />
            <property name="javax.persistence.jdbc.driver" value="org.postgresql.Driver" />
            <property name="javax.persistence.jdbc.user" value="user" />
            <property name="javax.persistence.jdbc.password" value="..." />
        </properties>
    </persistence-unit>
</persistence>

Затем добавьте фильтрацию тестовых ресурсов в ваш файл pom.xml:

<project>
    ...
    <build>
        ...
        <testResources>
            <testResource>
                <directory>src/test/resources</directory>
                <filtering>true</filtering>
            </testResource>
        </testResources>
        ...
    </build>
...
</project>

Это будет работать, потому что jar-file может предназначаться для каталогов, а не только для файлов JAR.

7
Vlad-HC

Я попробовал подход ClassLoaderProxy, но у меня была проблема с тем, что аннотированные классы JPA не обрабатываются как постоянные классы hibernate.

Поэтому решил попробовать это без использования файла persistence.xml. Преимущество заключается в том, что сборка maven и тест Eclipse JUnit будут работать без изменений.

У меня есть постоянный класс поддержки для тестирования JUnit.

public class PersistenceTestSupport {

    protected EntityManager em;
    protected EntityTransaction et;

    /**
     * Setup the the {@code EntityManager} and {@code EntityTransaction} for
     * local junit testing.
     */
    public void setup() {

        Properties props = new Properties();
        props.put("hibernate.hbm2ddl.auto", "create-drop");
        props.put("hibernate.dialect", "org.hibernate.dialect.MySQLDialect");
        props.put("hibernate.connection.url", "jdbc:mysql://localhost/db_name");
        props.put("hibernate.connection.driver_class", "com.mysql.jdbc.Driver");
        props.put("hibernate.connection.username", "user");
        props.put("hibernate.connection.password", "****");

        Ejb3Configuration cfg = new Ejb3Configuration();
        em = cfg.addProperties(props)
            .addAnnotatedClass(Class1.class)
            .addAnnotatedClass(Class2.class)
            ...
                    .addAnnotatedClass(Classn.class)
            .buildEntityManagerFactory()
            .createEntityManager();

        et = em.getTransaction();
    }
}

Мои тестовые классы просто расширяют PersistenceTestSupport и вызывают setup () в TestCase.setup ().

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

6
luzzy

Я предпочитаю решение использовать другой файл persistence.xml для тестирования и производства в качестве Rich Seller post (спасибо !!).

Но нужно поменять 

<copy file="${project.build.outputDirectory}/META-INF/persistence.xml.proper" tofile="${project.build.outputDirectory}/META-INF/persistence.xml"/>

за:

<move file="${project.build.outputDirectory}/META-INF/persistence.xml.proper" tofile="${project.build.outputDirectory}/META-INF/persistence.xml" overwrite="true"/>

Чтобы файл persistence.xml.proper не был встроен в файл .jar 

5
d.marzo

Сохраните две копии файла persistence.xml. Один для тестирования, а другой для нормальной сборки.

Жизненный цикл по умолчанию копирует сборку persistence.xml в src/test/resources/META-INF

Создайте отдельный профиль, который при запуске скопирует файл persistence.xml для тестирования в src/test/resources/META-INF

3
TRF

Этот ответ может показаться глупым, но я искал способ, позволяющий мне запускать эти тесты из Eclipse с помощью Run As -> JUnit Test. Вот как я это сделал:

@BeforeClass
public static void setUp() throws IOException {
    Files.copy(new File("target/test-classes/META-INF/persistence.xml"), new File("target/classes/META-INF/persistence.xml"));
    // ...
}

Я просто копирую test/persistence.xml в classes/persistence.xml. Это работает. 

3
Kai

Persistence.xml используется в качестве отправной точки для поиска классов сущностей, если вы явно не перечислите все классы и не добавите . Поэтому, если вы хотите переопределить этот файл другим, скажем, из src/test/resources, вы должны указать каждый отдельный класс сущностей в этом втором файле persistence.xml, иначе класс сущностей не будет найден.

Другим решением было бы перезаписать файл с помощью плагина maven-resources-plugin (цель «copy-resources»). Но затем вы должны перезаписать его дважды, один раз для тестирования (например, фазы process-test-classes) и один раз для реальной упаковки (фаза 'prepare-package').

3
Robin

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

Поместите оба модуля постоянства в файл persistence.xml реального проекта, и ваши тестовые примеры вставят правильный EntityManager. Пример ниже иллюстрирует, как сделать это с помощью guice. Пожалуйста, обратите внимание, что для полноты изложения я оставил макет mockito, соответствующий код mockito был помечен соответствующим образом и не требуется для инъекции.

public class HibernateTestDatabaseProvider extends AbstractModule {
    private static final ThreadLocal<EntityManager> ENTITYMANAGER_CACHE = new ThreadLocal<>();

    @Override
    public void configure() {
    }

    @Provides
    @Singleton
    public EntityManagerFactory provideEntityManagerFactory() {
        return Persistence.createEntityManagerFactory("my.test.persistence.unit");
    }

    @Provides
    public CriteriaBuilder provideCriteriaBuilder(EntityManagerFactory entityManagerFactory) {
        return entityManagerFactory.getCriteriaBuilder();
    }

    @Provides
    public EntityManager provideEntityManager(EntityManagerFactory entityManagerFactory) {
        EntityManager entityManager = ENTITYMANAGER_CACHE.get();
        if (entityManager == null) {
            // prevent commits on the database, requires mockito. Not relevant for this answer
            entityManager = spy(entityManagerFactory.createEntityManager());


            EntityTransaction et = spy(entityManager.getTransaction());
            when(entityManager.getTransaction()).thenReturn(et);
            doNothing().when(et).commit();

            ENTITYMANAGER_CACHE.set(entityManager);
        }
        return entityManager;
    }
}
1
siyb

При использовании OpenEJB файл persistence.xml можно переопределить с помощью альтернативных дескрипторов: http://tomee.Apache.org/alternate-descriptors.html

1
Milanka

Другой подход заключается в использовании отдельного файла persistence.xml для тестирования (test /../ META-INF/persistence.xml, но переопределите сканер следующим образом: -

тестирование persistence.xml должно содержать

<property name="hibernate.ejb.resource_scanner" value = "...TestScanner" />

Код для нового класса TestScanner выглядит следующим образом.

import Java.lang.annotation.Annotation;
import Java.net.MalformedURLException;
import Java.net.URL;
import Java.util.Set;
import org.hibernate.ejb.packaging.NamedInputStream;
import org.hibernate.ejb.packaging.NativeScanner;


public class TestScanner extends NativeScanner
{

@Override
public Set <Class <?> > 
getClassesInJar (URL jar, Set <Class <? extends Annotation> > annotations)
{  return super.getClassesInJar (getUpdatedURL (jar), annotations); }

@Override
public Set <NamedInputStream> 
getFilesInJar (URL jar, Set <String> patterns)
{  return super.getFilesInJar (getUpdatedURL (jar), patterns); }

@Override
public Set <Package> 
getPackagesInJar (URL jar, Set <Class <? extends Annotation> > annotations)
{  return super.getPackagesInJar (getUpdatedURL (jar), annotations); }

private URL getUpdatedURL (URL url)
{
  String oldURL = url.toExternalForm ();
  String newURL = oldURL.replaceAll ("test-classes", "classes");
  URL result;
  try {
    result = newURL.equals (oldURL) ? url : new URL (newURL);
  } catch (MalformedURLException e)
  {  // Whatever  }
  return result;
}

}
1
Steve Higham

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

Я наткнулся на статью в сети, где они использовали собственный загрузчик классов, чтобы сделать что-то подобное, что послужило вдохновением. Если кто-то может увидеть, как улучшить, то предложения будут приветствоваться, кстати. Для развертывания я полагаюсь на внедрение контейнера EntityManager, но для тестирования я создаю его сам, используя этот код:

final Thread currentThread = Thread.currentThread();
final ClassLoader saveClassLoader = currentThread.getContextClassLoader();
currentThread.setContextClassLoader(new ClassLoaderProxy(saveClassLoader));

EntityManagerFactory emFactory = Persistence.createEntityManagerFactory("test");
em = emFactory.createEntityManager();

Тогда ClassLoaderProxy будет настолько минимальным, насколько вы можете получить, и просто перенаправит запросы для META-INF/persistence.xml в META-INF/test-persist.xml:

public class ClassLoaderProxy extends ClassLoader {

    public ClassLoaderProxy(final ClassLoader parent) {
        super();
    }

    @Override
    public Enumeration<URL> getResources(final String name) throws IOException {
        if (!"META-INF/persistence.xml".equals(name)) {
            return super.getResources(name);
        } else {
            System.out.println("Redirecting persistence.xml to test-persist.xml");
            return super.getResources("META-INF/test-persist.xml");
        }
    }
}

Просто чтобы объяснить это немного подробнее:

  1. Существует два файла persistence.xml (один с именем persistence.xml, который используется вне тестирования, и один с именем test-persist.xml, который используется для тестов).
  2. Пользовательский загрузчик классов является только активным для модульных тестов (для развертывания все нормально)
  3. Пользовательский загрузчик классов перенаправляет запросы для «META-INF/persistence.xml» в тестовую версию («META-INF/test-persist.xml»). 

Изначально я столкнулся с некоторыми проблемами, потому что Hibernate вернется (каким-то образом) назад к загрузчику классов, который использовался для загрузки Hibernate (по крайней мере, я думаю, что это происходило). Я обнаружил, что, помещая код переключения ClassLoader (первый блок) в качестве статического блока в вашем тестовом примере, он будет загружен до Hibernate, но в зависимости от структуры вашего модульного теста вам также может понадобиться поместить этот код в другие места. (Тьфу).

1
macbutch

поставить тесты в собственный проект maven с его сохранением.xml 

0
balmaster

Это расширение ответа Rich Seller с правильной обработкой Hibernate для поиска нескольких файлов persistence.xml в пути к классам и восстановления состояния перед тестированием.

Настроить:

Создайте один файл персистентности для развертывания/упаковки и один для тестирования:

  • sRC/главная/ресурсы/persistence.xml

  • src / тест / ресурсы/постоянство - тестирование . xml

в вашем pom.xml добавьте это в раздел плагинов:

        <plugin>
            <artifactId>maven-antrun-plugin</artifactId>
            <version>1.3</version>
            <executions>
                <execution>
                    <id>copy-test-persistence</id>
                    <phase>process-test-resources</phase>
                    <configuration>
                        <tasks>
                            <echo>renaming deployment persistence.xml</echo>
                            <move file="${project.build.outputDirectory}/META-INF/persistence.xml" tofile="${project.build.outputDirectory}/META-INF/persistence.xml.proper"/>
                            <echo>replacing deployment persistence.xml with test version</echo>
                            <copy file="${project.build.testOutputDirectory}/META-INF/persistence-testing.xml" tofile="${project.build.outputDirectory}/META-INF/persistence.xml" overwrite="true"/>
                        </tasks>
                    </configuration>
                    <goals>
                        <goal>run</goal>
                    </goals>
                </execution>
                <execution>
                    <id>restore-persistence</id>
                    <phase>prepare-package</phase>
                    <configuration>
                        <tasks>
                            <echo>restoring the deployment persistence.xml</echo>
                            <move file="${project.build.outputDirectory}/META-INF/persistence.xml.proper" tofile="${project.build.outputDirectory}/META-INF/persistence.xml" overwrite="true"/>
                        </tasks>
                    </configuration>
                    <goals>
                        <goal>run</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>

Преимущества перед другими решениями

  • Никакого дополнительного кода Java не требуется
  • Только один файл persistence.xml на пути к классам
  • И сборка, и тестирование работают как положено
  • Описание вывода на консоль (эхо)
  • Для упаковки состояние восстановлено на 100%. Нет остатков файлов
0
Hubert Grzeskowiak

Я бы посоветовал использовать разные профили maven, где вы можете фильтровать файлы database.proprerties и иметь один database.properties для каждого профиля.

Таким образом, вам не нужно хранить дубликаты любых других файлов конфигурации, кроме .properties.

<properties>
    <!-- Used to locate the profile specific configuration file. -->
    <build.profile.id>default</build.profile.id>
    <!-- Only unit tests are run by default. -->
    <skip.integration.tests>true</skip.integration.tests>
    <skip.unit.tests>false</skip.unit.tests>
    <integration.test.files>**/*IT.Java</integration.test.files>
</properties>
<profiles>
    <profile>
        <id>default</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <!--
                Specifies the build profile id, which is used to find out the correct properties file.
                This is not actually necessary for this example, but it can be used for other purposes.
            -->
            <build.profile.id>default</build.profile.id>
            <skip.integration.tests>true</skip.integration.tests>
            <skip.unit.tests>false</skip.unit.tests>
        </properties>
        <build>
            <filters>
                <!--
                    Specifies path to the properties file, which contains profile specific
                    configuration. In this case, the configuration file should be the default spring/database.properties file
                -->
                <filter>src/main/resources/META-INF/spring/database.properties</filter>
            </filters>
            <resources>
                <!--
                    Placeholders found from files located in the configured resource directories are replaced
                    with values found from the profile specific configuration files.
                -->
                <resource>
                    <filtering>true</filtering>
                    <directory>src/main/resources</directory>
                    <!--
                        You can also include only specific files found from the configured directory or
                        exclude files. This can be done by uncommenting following sections and adding
                        the configuration under includes and excludes tags.
                    -->
                    <!--
                    <includes>
                        <include></include>
                    </includes>
                    <excludes>
                        <exclude></exclude>
                    </excludes>
                    -->
                </resource>
            </resources>
        </build>
    </profile>
    <profile>
        <id>integration</id>
        <properties>
            <!--
                Specifies the build profile id, which is used to find out the correct properties file.
                This is not actually necessary for this example, but it can be used for other purposes.
            -->
            <build.profile.id>integration</build.profile.id>
            <skip.integration.tests>false</skip.integration.tests>
            <skip.unit.tests>true</skip.unit.tests>
        </properties>
        <build>
            <filters>
                <!--
                    Specifies path to the properties file, which contains profile specific
                    configuration. In this case, the configuration file is searched
                    from spring/profiles/it/ directory.
                -->
                <filter>src/main/resources/META-INF/spring/profiles/${build.profile.id}/database.properties</filter>
            </filters>
            <resources>
                <!--
                    Placeholders found from files located in the configured resource directories are replaced
                    with values found from the profile specific configuration files.
                -->
                <resource>
                    <filtering>true</filtering>
                    <directory>src/main/resources</directory>
                    <!--
                        You can also include only specific files found from the configured directory or
                        exclude files. This can be done by uncommenting following sections and adding
                        the configuration under includes and excludes tags.
                    -->
                    <!--
                    <includes>
                        <include></include>
                    </includes>
                    <excludes>
                        <exclude></exclude>
                    </excludes>
                    -->
                </resource>
            </resources>
        </build>
    </profile>
</profiles>

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

    <plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.12</version>
    <configuration>
        <junitArtifactName>org.junit:com.springsource.org.junit</junitArtifactName>
        <!--see: https://issuetracker.springsource.com/browse/EBR-220-->
        <printSummary>false</printSummary>
        <redirectTestOutputToFile>true</redirectTestOutputToFile>
        <!-- Skips unit tests if the value of skip.unit.tests property is true -->
        <skipTests>${skip.unit.tests}</skipTests>
        <!-- Excludes integration tests when unit tests are run. -->
        <excludes>
            <exclude>${integration.test.files}</exclude>
        </excludes>
    </configuration>
</plugin>


<plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>2.12</version>
    <configuration>
        <!-- Skips integration tests if the value of skip.integration.tests property is true -->
        <skipTests>${skip.integration.tests}</skipTests>
        <includes>
            <include>${integration.test.files}</include>
        </includes>
        <forkMode>once</forkMode>
        <!--
                            <reuseForks>false</reuseForks>
                            <forkCount>1</forkCount>
        -->
    </configuration>
    <executions>
        <execution>
            <id>integration-test</id>
            <goals>
                <goal>integration-test</goal>
            </goals>
        </execution>
        <execution>
            <id>verify</id>
            <goals>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Теперь вам нужно только mvn test для ваших модульных тестов и mvn verify -Pintegration для ваших интеграционных тестов . Очевидно, вы должны создать файлы database.properties по указанным (в профилях) путям (или в других местах и ​​изменить пути)

На основе ссылки: http://www.petrikainulainen.net/programming/tips-and-tricks/creating-profile-specific-configuration-files-with-maven/

0
Chris