wake-up-neo.com

So konfigurieren Sie JPA zum Testen in Maven

Gibt es eine Möglichkeit, eine zweite persistence.xml-Datei in einem Maven-Projekt so einzurichten, dass sie zum Testen anstelle der normalen für die Bereitstellung verwendeten verwendet wird?

Ich habe versucht, eine persistence.xml in src/test/resources/META-INF zu setzen, die in target/test-classes/META-INF kopiert wird, aber es scheint Target/classes/META-INF (die Kopie von src/main) zu sein/resources) wird bevorzugt, obwohl mvn -X test die Klassenpfadeinträge in der richtigen Reihenfolge auflistet:

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

Ich möchte in der Lage sein, Tests mit einer einfachen hsqldb-Konfiguration auszuführen, ohne die Implementierungsversion der JPA-Konfiguration ändern zu müssen, idealerweise direkt nach der Projektüberprüfung, ohne dass lokale Anpassungen erforderlich sind.

65
Peter Becker

Folgendes funktioniert für Maven 2.1+ (davor gab es keine Phase zwischen Test und Paket, an die Sie eine Ausführung binden könnten).

Sie können das maven-antrun-plugin verwenden, um die persistence.xml für die Dauer der Tests durch die Testversion zu ersetzen. Stellen Sie dann die richtige Version wieder her, bevor das Projekt gepackt wird.

In diesem Beispiel wird davon ausgegangen, dass die Produktionsversion src/main/resources/META-INF/persistence.xml und die Testversion src/test/resources/META-INF/persistence.xml ist, sodass sie in target/classes/META kopiert werden -INF und Target/Test-Klassen/META-INF.

Es wäre eleganter, dies in einem Mojo zu verkapseln, aber da Sie nur eine Datei kopieren, erscheint es als übertrieben.

<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

In einem EE6/CDI/JPA-Projekt wird ein Test src/test/resources/META-INF/persistence.xml ohne weitere Konfiguration genau genommen.

Wenn Sie JPA in Spring verwenden, funktioniert Folgendes im Anwendungskontext, der zum Testen verwendet wird:

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

Hier wäre /src/test/resources/META-INF/persistence.xml (in target/test-classes kopiert) gegenüber /src/main/resources/META-INF/persistence.xml (in target/classes kopiert) zu bevorzugen.

Leider bestimmt der Speicherort der persistence.xml-Datei auch das sogenannte " Persistence Unit-Stammverzeichnis ", das dann ermittelt, welche Klassen nach @Entity-Anmerkungen durchsucht werden. Wenn Sie /src/test/resources/META-INF/persistence.xml verwenden, werden Klassen in target/test-classes durchsucht, nicht Klassen in target/classes (wo die Klassen, die getestet werden müssen, leben würden). 

Daher müssen zum Testen <class>-Einträge explizit zu persistence.xml hinzugefügt werden, um Java.lang.IllegalArgumentException: Not an entity: class ... zu vermeiden. Die Notwendigkeit von <class>-Einträgen kann vermieden werden, indem ein anderer Dateiname wie persistence-TEST.xml verwendet wird und sich diese Datei in demselben Ordner wie die normale persistence.xml-Datei befindet. Der Spring-Kontext aus Ihrem Testordner kann dann einfach auf <property name="persistenceXmlLocation" value="META-INF/persistence-TEST.xml" /> verweisen, und Spring findet ihn in src/main für Sie.

Alternativ kann man persistence.xml für die eigentliche Anwendung und die Tests gleich halten und nur einen in src/main definieren. Die meisten Konfigurationen wie Treiber, Dialekt und optionale Anmeldeinformationen können stattdessen im Spring-Kontext vorgenommen werden. Auch Einstellungen wie hibernate.hbm2ddl.auto können im Kontext übergeben werden :

<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

Es scheint, dass mehrere persistence.xml-Dateien ein allgemeines Problem mit JPA sind, das nur durch Trick beim Classloading gelöst werden kann.

Eine Problemumgehung, die für mich funktioniert, besteht darin, mehrere Persistenzeinheiten in einer Datei persistence.xml zu definieren und anschließend sicherzustellen, dass der Bereitstellungs- und Testcode eine andere Bindung verwendet (in Spring können Sie die Eigenschaft "persistenceUnitName" für die Entity Manager Factory festlegen). Es verschmutzt Ihre Implementierungsdatei mit der Testkonfiguration, aber wenn Sie nichts dagegen haben, dass es in Ordnung ist.

13
Peter Becker

Fügen Sie eine persistance.xml für Tests hinzu: /src/test/resources/META-INF/persistence.xml Wie @Arjan sagte, dass sich die Wurzel der persistance unit ändern würde, und Entitätsklassen würden in Ziel Testklassen gescannt werden. Fügen Sie dem persistance.xml-Element jar-file hinzu:

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

Fügen Sie anschließend der pom.xml eine Filterung der Testressourcen hinzu:

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

Dies funktioniert, weil jar-file Verzeichnisse ansprechen kann und nicht nur JAR-Dateien.

7
Vlad-HC

Ich habe den ClassLoaderProxy-Ansatz ausprobiert, hatte jedoch das Problem, dass die mit Anmerkungen versehenen JPA-Klassen nicht als persistente Klassen vom Ruhezustand behandelt werden.

Also entschied ich mich, es ohne persistence.xml auszuprobieren. Der Vorteil ist, dass der Maven Build und der Eclipse JUnit-Test ohne Änderungen funktionieren.

Ich habe eine dauerhafte Support-Klasse für JUnit-Tests.

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();
    }
}

Meine Testklassen erweitern lediglich PersistenceTestSupport und rufen das setup () in TestCase.setup () auf.

Der einzige Nachteil besteht darin, die persistenten Klassen auf dem neuesten Stand zu halten, aber für JUnit-Tests ist dies für mich akzeptabel.

6
luzzy

Ich bevorzuge die Lösung der Verwendung verschiedener persistence.xml zum Testen und Produzieren als Rich Seller post (Danke !!).

Muss sich aber ändern: 

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

zum:

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

Damit persistence.xml.proper nicht in die .jar-Datei eingebettet wird 

5
d.marzo

Behalten Sie zwei Kopien der Datei persistence.xml. Einer zum Testen und ein anderer für den normalen Build.

Der Standardlebenszyklus kopiert die build persistence.xml nach src/test/resources/META-INF

Erstellen Sie ein separates Profil, das bei Ausführung die persistence.xml-Testdatei nach src/test/resources/META-INF kopiert

3
TRF

Diese Antwort klingt vielleicht dumm, aber ich suchte nach einer Möglichkeit, diese Tests von Eclipse über Run As -> JUnit Test auszuführen. So habe ich es gemacht:

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

Ich kopiere gerade die test/persistence.xml nach classes/persistence.xml. Das funktioniert. 

3
Kai

Persistence.xml wird als Ausgangspunkt für die Suche nach Entitätsklassen verwendet, es sei denn, Sie listen alle Klassen explizit auf und fügen .. .. hinzu. Wenn Sie diese Datei mit einer anderen überschreiben möchten, z. B. von src/test/resources, müssen Sie dies angeben Jede einzelne Entitätsklasse in dieser zweiten persistence.xml wird sonst nicht gefunden.

Eine andere Lösung wäre das Überschreiben der Datei mit dem Maven-Resources-Plugin (Ziel 'copy-resources'). Dann müssen Sie es jedoch zweimal überschreiben, einmal zum Testen (z. B. Phase Process-Test-Klassen) und einmal für die reale Verpackung (Phase "Prepare-Package").

3
Robin

Eine weitere Option für diesen Anwendungsfall wäre das Hinzufügen mehrerer Persistenz-Einheiten, eine für die Produktions- und eine andere zum Testen und die entsprechende Einfügung der EntityManagerFactory.

Platzieren Sie beide Persistence-Units in der Persistence.xml des aktuellen Projekts und lassen Sie Ihre Testfälle den richtigen EntityManager einfügen. Das folgende Beispiel zeigt, wie das mit guice gemacht wird. Bitte beachten Sie, dass ich der Vollständigkeit halber Mockito-Spott gelassen habe. Der Mockito-spezifische Code wurde entsprechend gekennzeichnet und ist für die Injektion nicht erforderlich.

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

Wenn Sie OpenEJB verwenden, kann persistence.xml mit alternativen Deskriptoren: http://tomee.Apache.org/alternate-descriptors.html überschrieben werden.

1
Milanka

Ein anderer Ansatz ist die Verwendung einer separaten persistence.xml zum Testen (test /../ META-INF/persistence.xml, den Scanner jedoch wie folgt überschreiben:

das Testen von persistence.xml muss enthalten

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

Code für die neue Klasse TestScanner lautet wie folgt.

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

Ich versuche das Gleiche zu tun. Ich habe eine Lösung, die für mich funktioniert - Ihre kann variieren (und Sie werden die Lösung vielleicht nicht lieben ... es ist ein bisschen niedrig).

Ich stieß auf einen Artikel im Internet, in dem sie einen benutzerdefinierten Klassenlader verwendeten, um etwas Ähnliches zu tun, das als Inspiration diente. Wenn irgendjemand sehen kann, wie man sich verbessern kann, wären Vorschläge übrigens willkommen. Für die Bereitstellung stütze ich mich auf die Containerinjektion des EntityManagers, aber zum Testen erstelle ich es selbst mit diesem Code:

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

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

Dann ist der ClassLoaderProxy so minimal wie Sie nur bekommen können und leitet Anforderungen einfach nach META-INF/persistence.xml an META-INF/test-persist.xml weiter:

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

Um dies etwas mehr zu erklären:

  1. Es gibt zwei persistence.xml-Dateien (eine mit dem Namen persistence.xml, die außerhalb des Testens verwendet wird, und eine mit dem Namen test-persist.xml, die für Tests verwendet wird).
  2. Der benutzerdefinierte Klassenlader ist nur aktiv für Komponententests (für die Bereitstellung ist alles normal)
  3. Das benutzerdefinierte Klassenladeprogramm leitet Anforderungen für "META-INF/persistence.xml" an die Testversion ("META-INF/test-persist.xml") um. 

Ich hatte ursprünglich einige Probleme, weil Hibernate (irgendwie) auf den Classloader zurückgreift, der zum Laden von Hibernate verwendet wurde (zumindest glaube ich, dass dies der Fall war). Wenn Sie den ClassLoader-Umschaltcode (den ersten Block) als statischen Block in Ihren Testfall setzen, wird er vor dem Ruhezustand geladen. Je nach Geräteteststruktur müssen Sie jedoch möglicherweise denselben Code auch an anderen Stellen einfügen (yuck).

1
macbutch

teste mit seiner persistence.xml eigene Maven-Projekte 

0
balmaster

Dies ist eine Erweiterung der Antwort von Rich Seller mit der richtigen Behandlung von Hibernate, wobei mehrere persistence.xml-Dateien im Klassenpfad gesucht werden und der Zustand vor dem Testen wiederhergestellt wird.

Konfiguration:

Erstellen Sie eine Persistenzdatei zum Bereitstellen/Packen und eine zum Testen:

  • src/main/resources/persistence.xml

  • src / test / resources/persistence - testing . xml

fügen Sie dies in Ihrer pom.xml zum Plugins-Abschnitt hinzu:

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

Vorteile gegenüber anderen Lösungen

  • Kein zusätzlicher Java-Code erforderlich
  • Nur eine persistence.xml für classpath
  • Sowohl das Bauen als auch das Testen funktionieren wie erwartet
  • Beschreiben der Ausgabe auf der Konsole (Echo)
  • Für die Verpackung wird der Zustand zu 100% wiederhergestellt. Keine Dateien übrig
0

Ich würde empfehlen, verschiedene Maven-Profile zu verwenden, in denen Sie Ihre database.proprerties-Dateien filtern können und pro Profil eine database.properties haben.

Auf diese Weise müssen Sie keine Duplikate anderer Konfigurationsdateien außer den .properties aufbewahren.

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

Mit Hilfe von Surefire für Unit-Tests und Failure-Tests für Integrationstests sind Sie fertig.

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

Jetzt benötigen Sie nur noch mvn test für Ihre Unit-Tests und mvn verify -Pintegration für Ihre Integrationstests Natürlich sollten Sie die Dateien database.properties in den angegebenen Pfaden (in den Profilen) (oder anderswo) erstellen und die Pfade ändern.

Basierend auf Referenz: http://www.petrikainulainen.net/programmierung/tips-and-tricks/creating-profile-specific-configuration-files-with-maven/

0
Chris