Comment configurer JPA pour les essais dans Maven

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

Lors de l'utilisation de JPA au Printemps, les travaux suivants dans le contexte de l'application utilisée pour le test:

<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) seraient préférables /src/main/resources/META-INF/persistence.xml (copié dans target/classes).

Malheureusement, l'emplacement de la persistence.xml fichier détermine également la soi-disant "unité de persistance de la racine", qui détermine les classes qui sont analysés pour @Entity annotations. Ainsi, l'utilisation de /src/test/resources/META-INF/persistence.xml numériser des classes dans target/test-classes, et non des classes dans target/classes (où les classes qui doivent être testés vivraient).

Donc, pour les essais, on aurait besoin d'ajouter explicitement <class> entrées à persistence.xml, pour éviter java.lang.IllegalArgumentException: Not an entity: class .... La nécessité pour <class> entrées peuvent être évités par l'utilisation d'un nom de fichier différent, comme persistence-TEST.xml, et de mettre ce fichier dans le même dossier que l'ordinaire de persistence.xml fichier. Le Printemps de contexte à partir de votre dossier de test peut alors tout simplement se référer à <property name="persistenceXmlLocation" value="META-INF/persistence-TEST.xml" />, et le Printemps va le trouver pour vous dans src/main.

Comme une alternative, on pourrait être en mesure de garder persistence.xml la même pour l'application et les tests, et seulement de définir un dans src/main. La plupart de configuration tels que les pilotes, le dialecte et facultatif des informations d'identification qui peut être fait au Printemps contexte à la place. Également des paramètres tels que hibernate.hbm2ddl.auto peut être adoptée 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>

Ajouter un persistance.xml pour les tests: /src/test/resources/META-INF/persistence.xml
Comme @Arjan dit, cela changerait la persistance de l'unité de la racine et les classes d'entité serait balayé dans la cible/test-classes. Pour gérer cela, il faut ajouter jar-file élément à ce 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>

Ensuite, ajouter le filtrage des ressources de test pour votre pom.xml:

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

Cela fonctionne parce que jar-file pouvez cibler répertoires, non seulement pour les fichiers jar.

Je préfère la solution de l'utilisation de différents persistence.xml pour les essais et la production aussi Riche Vendeur post (merci!!).

Mais besoin de 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"/>

Afin de persistance.xml.bon pas incorporé .fichier jar

Persistence.xml est utilisé comme un point de départ à la recherche pour les classes d'entité, sauf si vous avez la liste de toutes les classes de façon explicite et les ajouter .
Donc, si vous voulez remplacer ce fichier par un autre, disons de la src/test/resources, vous devez spécifier à chaque classe d'entité dans cette deuxième persistence.xml sinon pas de classe d'entité serait trouvée.

Une autre solution serait de remplacer le fichier à l'aide de l'maven-ressources-plugin ("copier-ressources de but). Mais alors vous devez le remplacer par deux fois, une fois pour les tests (par exemple, la phase du processus de test-classes) et une fois pour le réel de l'emballage (phase "préparez-package").

Je suis en train de faire la même chose. J'ai une solution qui fonctionne pour moi - vous peut varier (et vous risquez de ne pas aimer la solution... c'est un peu bas niveau).

Je suis tombé sur un article sur le net où ils ont été à l'aide d'un personnalisé du chargeur de classe pour faire quelque chose de similaire qui a servi comme source d'inspiration. Si quelqu'un peut voir comment améliorer ensuite les suggestions sont les bienvenue btw. Pour le déploiement, je m'appuie sur le conteneur d'injection de l'EntityManager, mais pour les essais j'ai créer 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();

Puis le ClassLoaderProxy est aussi minime que vous pouvez obtenir et juste redirige les demandes de META-INF/persistence.xml pour 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 un peu plus:

1. Il y a deux persistence.xml les fichiers (un nommé persistence.xml qui est utilisé à l'extérieur des tests et un nommé test-persist.xml qui est utilisé pour les tests).
2. De la classe personnalisée, chargeur est seulement active pour les tests unitaires (pour le déploiement, tout est normal)
3. De la classe personnalisée, chargeur redirige les demandes d' "META-INF/persistence.xml" à la version de test ("META-INF/test-persist.xml").

J'ai été à l'origine de frapper certains problèmes parce que Hibernate va revenir (en quelque sorte) pour le chargeur de classe qui a été utilisé pour charger mise en veille prolongée (au moins je pense que c'est ce qui se passait). J'ai trouvé que le fait de mettre le chargeur de classe code de commutation (premier bloc) comme un bloc statique dans votre cas de Test, il sera chargé avant Hibernate, mais qui, en fonction de votre structure de test vous pouvez aussi avoir besoin de mettre le même code dans d'autres lieux (beurk).

Lors de l'utilisation d'OpenEJB, persistence.xml peut être remplacé par suppléant descripteurs: http://tomee.apache.org/alternate-descriptors.html

Une autre option pour ce cas d'utilisation serait l'ajout de plusieurs unités de persistance, un pour permet de dire que la production et l'autre pour les tests et d'injecter de l'EntityManagerFactory en conséquence.

Lieu à la fois de la persistance-unités dans le persistence.xml du projet lui-même et avoir vos cas de test injecter la bonne EntityManager. L'exemple ci-dessous illustre comment le faire avec guice. Veuillez noter que j'ai laissé dans certains mockito moqueur pour être complet, le mockito code spécifique a été marquée 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;
    }
}

Je suggérerais à l'aide de différents profils maven où vous pouvez filtrer votre base de données.proprerties fichiers, et d'une base de données.propriétés en fonction du profil.

De cette façon, vous n'avez pas à garder des doubles de toutes les autres fichiers de configuration à l'exception de l' .les propriétés.

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

Maintenant, vous avez juste besoin de mvn test pour vos tests unitaires et mvn verify -Pintegration pour vos tests d'intégration.
Évidemment, vous devez créer la base de données.des fichiers de propriétés spécifiées (sur les profils) chemins (ou ailleurs et modifier les chemins d'accès)

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