web-dev-qa-db-fra.com

Comment configurer JPA pour les tests dans Maven

Existe-t-il un moyen de configurer un deuxième fichier persistence.xml dans un projet Maven, de sorte qu'il soit utilisé pour les tests au lieu du fichier normal utilisé pour le déploiement?

J'ai essayé de placer un fichier persistence.xml dans src/test/resources/META-INF, qui est copié dans target/test-classes/META-INF, mais il semble que target/classes/META-INF/resources) est préféré, malgré que mvn -X test ait répertorié les entrées du chemin de classe dans le bon ordre:

[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
...

J'aimerais pouvoir effectuer des tests sur une configuration simple de hsqldb sans avoir à modifier la version de déploiement de la configuration de JPA, idéalement juste après la vérification du projet sans avoir besoin de peaufiner le système au niveau local.

javatestingmaven-2jpaintegration-testing
65
Peter Becker

Ce qui suit fonctionnera pour Maven 2.1+ (avant cela, il n'y avait pas de phase entre test et package à laquelle vous pouviez lier une exécution).

Vous pouvez utiliser le plugin maven-antrun-plugin pour remplacer le fichier persistence.xml par la version de test pendant la durée des tests, puis restaurer la version appropriée avant que le projet ne soit empaqueté.

Cet exemple suppose que la version de production est src/main/resources/META-INF/persistence.xml et que la version de test est src/test/resources/META-INF/persistence.xml. Elles seront donc copiées dans target/classes/META. -INF et cible/test-classes/META-INF respectivement.

Il serait plus élégant d’encapsuler cela dans un mojo, mais comme vous ne faites que copier un fichier, cela semble excessif.

<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

Dans un projet EE6/CDI/JPA, un test src/test/resources/META-INF/persistence.xml est correctement pris sans aucune configuration supplémentaire.

Lors de l'utilisation de JPA dans Spring, les éléments suivants fonctionnent dans le contexte d'application utilisé pour les tests:

<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>

Ici, /src/test/resources/META-INF/persistence.xml (copié dans target/test-classes) serait préféré à /src/main/resources/META-INF/persistence.xml (copié dans target/classes).

Malheureusement, l'emplacement du fichier persistence.xml détermine également la soi-disant " racine de l'unité de persistance }", qui détermine ensuite les classes analysées pour les annotations @Entity. Donc, utiliser /src/test/resources/META-INF/persistence.xml scanne les classes dans target/test-classes, pas les classes dans target/classes (où vivraient les classes à tester). 

Par conséquent, pour tester, il faudrait explicitement ajouter des entrées <class> à persistence.xml, pour éviter Java.lang.IllegalArgumentException: Not an entity: class .... Le besoin d'entrées <class> peut être évité en utilisant un nom de fichier différent, tel que persistence-TEST.xml, et en plaçant ce fichier dans le même dossier que le fichier persistence.xml normal. Le contexte Spring de votre dossier de test peut alors simplement faire référence à <property name="persistenceXmlLocation" value="META-INF/persistence-TEST.xml" />, et Spring le trouvera pour vous dans src/main.

En guise d'alternative, on pourrait peut-être garder persistence.xml identique pour l'application réelle et les tests, et n'en définir qu'un dans src/main. La plupart des configurations telles que les pilotes, le dialecte et les informations d'identification facultatives peuvent être effectuées dans le contexte Spring. Les paramètres tels que hibernate.hbm2ddl.auto peuvent également être transmis dans le contexte } _:

<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

Il semble que plusieurs fichiers persistence.xml soient un problème général avec JPA, résolu uniquement par des astuces de chargement de classes.

Une solution de contournement qui me convient consiste à définir plusieurs unités de persistance dans un fichier persistence.xml, puis à vous assurer que votre code de déploiement et de test utilise une liaison différente (dans Spring, vous pouvez définir la propriété "persistenceUnitName" sur la fabrique du gestionnaire d'entités). La configuration de test pollue votre fichier de déploiement, mais si cela ne vous dérange pas, cela fonctionne bien.

13
Peter Becker

Ajoutez un fichier persistance.xml pour les tests: /src/test/resources/META-INF/persistence.xml Comme @Arjan l'a déclaré, cela changerait racine de l'unité de persistance et les classes d'entités seraient analysées dans les classes cible/test. Pour gérer cela, ajoutez l'élément jar-file à ce fichier 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>

Ajoutez ensuite le filtrage des ressources de test à votre fichier pom.xml:

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

Cela fonctionnera car jar-file peut cibler des répertoires, pas seulement des fichiers jar.

7
Vlad-HC

J'ai essayé l'approche ClassLoaderProxy mais le problème était que les classes annotées JPA ne sont pas gérées comme des classes persistantes par hibernate.

Alors décidé de l'essayer sans utiliser persistence.xml. L'avantage est que la construction maven et le test Eclipse JUnit fonctionneront sans modifications.

J'ai une classe de support persitent pour les tests 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();
    }
}

Mes classes de test étendent simplement PersistenceTestSupport et appellent setup () dans TestCase.setup ().

Le seul inconvénient est de garder les classes persistantes à jour, mais pour les tests de JUnit, cela est acceptable pour moi.

6
luzzy

Je préfère la solution consistant à utiliser différents fichiers persistence.xml pour les tests et la production tels que Rich Seller post (merci !!).

Mais il faut changer: 

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

pour:

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

Dans l'ordre persistence.xml.proper non incorporé au fichier .jar 

5
d.marzo

Conservez deux copies du fichier persistence.xml. Un pour les tests et un autre pour la construction normale.

Le cycle de vie par défaut copie le build persistence.xml dans src/test/resources/META-INF.

Créez un profil distinct qui, une fois exécuté, copiera le fichier testing persistence.xml dans src/test/resources/META-INF.

3
TRF

Cette réponse peut paraître idiote, mais je cherchais un moyen de me permettre d'exécuter ces tests à partir d'Eclipse avec Run As -> JUnit Test. Voici comment je l'ai fait:

@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"));
    // ...
}

Je ne fais que copier le fichier test/persistence.xml dans classes/persistence.xml. Cela marche. 

3
Kai

Persistence.xml est utilisé comme point de départ pour rechercher des classes d'entités, sauf si vous répertoriez toutes les classes de manière explicite et ajoutez ensuite . Par conséquent, si vous souhaitez remplacer ce fichier par un autre, par exemple depuis src/test/resources, vous devez spécifier chaque classe d'entité dans ce deuxième fichier persistence.xml, sinon aucune classe d'entité ne serait trouvée.

Une autre solution serait d’écraser le fichier à l’aide du plugin maven-resources-plugin (objectif 'copy-resources'). Mais vous devez ensuite l'écraser deux fois, une fois pour le test (par exemple, processus de processus de phase) et une fois pour le conditionnement réel (phase 'prepare-package').

3
Robin

Une autre option pour ce cas d'utilisation serait d'ajouter plusieurs unités de persistance, une pour la production, une autre pour tester et injecter EntityManagerFactory en conséquence.

Placez les deux unités de persistance dans le fichier persistence.xml du projet réel et demandez à vos scénarios de test d'injecter EntityManager approprié. L'exemple ci-dessous montre comment procéder avec guice. S'il vous plaît noter que j'ai laissé dans certains mockito se moquant de la complétude, le code spécifique de mockito a été marqué en conséquence et n'est pas nécessaire pour l'injection.

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

Si vous utilisez OpenEJB, persistence.xml peut être remplacé par les descripteurs substituts: http://tomee.Apache.org/alternate-descriptors.html

1
Milanka

Une autre approche consiste à utiliser un fichier persistence.xml distinct pour le test (test /../ META-INF/persistence.xml, mais remplace le scanner comme suit:

le test de persistance.xml doit contenir

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

Le code pour la nouvelle classe TestScanner est le suivant.

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

J'essaie de faire la même chose. J'ai une solution qui fonctionne pour moi - la vôtre peut varier (et vous pourriez ne pas aimer la solution… c'est un peu bas niveau).

Je suis tombé sur un article sur le net où ils utilisaient un chargeur de classes personnalisé pour faire quelque chose de similaire qui a servi d'inspiration. Si quelqu'un peut voir comment s'améliorer, les suggestions seraient les bienvenues. Pour le déploiement, je m'appuie sur l'injection de conteneur de EntityManager, mais pour le tester, je le crée moi-même à l'aide de ce code:

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

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

Ensuite, ClassLoaderProxy est à peu près aussi minime que vous pouvez l’obtenir et redirige simplement les demandes de META-INF/persistence.xml vers 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");
        }
    }
}

Juste pour expliquer cela un peu plus:

  1. Il existe deux fichiers persistence.xml (un nommé persistence.xml utilisé en dehors des tests et un autre appelé test-persist.xml utilisé pour les tests).
  2. Le chargeur de classe personnalisé est seulement actif pour les tests unitaires (pour le déploiement, tout est normal)
  3. Le chargeur de classes personnalisé redirige les demandes de "META-INF/persistence.xml" vers la version test ("META-INF/test-persist.xml"). 

Au départ, je rencontrais des problèmes car Hibernate reviendrait (en quelque sorte) au chargeur de classe utilisé pour charger Hibernate (du moins, je pense, que c'était ce qui se passait). J'ai constaté qu'en plaçant le code de commutation ClassLoader (le premier bloc) en tant que bloc statique dans votre scénario de test, il sera chargé avant Hibernate, mais qu'en fonction de la structure de test de votre unité, vous devrez peut-être également placer le même code ailleurs. (beurk).

1
macbutch

mettre des tests dans son propre projet maven avec son persistence.xml 

0
balmaster

Il s’agit d’une extension de la réponse de Rich Seller avec la gestion appropriée d’Hibernate, qui consiste à rechercher plusieurs fichiers persistence.xml sur le chemin de classe et à restaurer l’état des tests.

Installer:

Créez un fichier de persistance pour le déploiement/conditionnement et un pour les tests:

  • src/main/resources/persistence.xml

  • src / test / ressources/persistance - test . xml

dans votre pom.xml ajoutez ceci à la section plugins:

        <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>

Avantages par rapport aux autres solutions

  • Aucun code Java supplémentaire requis
  • Un seul fichier persistence.xml sur le chemin de classe
  • La construction et les tests fonctionnent comme prévu
  • Description de la sortie sur la console (echo)
  • Pour l'emballage, l'état est restauré à 100%. Pas de fichiers restants
0
Hubert Grzeskowiak

Je suggérerais d'utiliser différents profils Maven dans lesquels vous pouvez filtrer vos fichiers database.proprerties et obtenir un fichier database.properties par profil.

De cette façon, vous n’avez pas à garder les doublons d’autres fichiers de configuration, à l’exception des fichiers .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>

Avec l'aide de surefire pour les tests unitaires et d'échec pour les tests d'intégration, vous avez terminé.

    <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>

Désormais, il vous suffit de mvn test pour vos tests unitaires et de mvn verify -Pintegration pour vos tests d'intégration . De toute évidence, vous devez créer les fichiers database.properties dans les chemins spécifiés (sur les profils) (ou ailleurs, et modifier les chemins).

Basé sur la référence: http://www.petrikainulainen.net/programming/tips-and-tricks/creating-profile-specific-configuration-files-with-maven/

0
Chris