Maven에서 테스트를 위해 JPA를 구성하는 방법
배포에 사용되는 일반 파일 대신 테스트에 사용되도록 Maven 프로젝트에서 두 번째 persistence.xml 파일을 설정하는 방법이 있습니까?
나는 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
...
JPA 구성의 배포 버전을 변경할 필요없이 간단한 hsqldb 구성에 대해 테스트를 실행할 수 있기를 바랍니다. 이상적으로는 로컬 조정없이 프로젝트 체크 아웃 직후에 바로 수행 할 수 있습니다.
다음은 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 및 대상 / 테스트 클래스 / 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>
EE6 / CDI / JPA 프로젝트에서는 src/test/resources/META-INF/persistence.xml추가 구성없이 테스트 가 잘 선택됩니다.
Spring에서 JPA를 사용할 때 테스트에 사용되는 애플리케이션 컨텍스트에서 다음이 작동합니다.
<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파일 의 위치는 소위 " 지속성 유닛의 루트 "를 결정하고 @Entity주석을 검색 할 클래스를 결정 합니다. 따라서를 사용 /src/test/resources/META-INF/persistence.xml하면의 클래스가 target/test-classes아닌 에서 클래스를 스캔 target/classes합니다 (테스트해야하는 클래스가있는 위치).
따라서 테스트 를 위해를 피하기 위해에 <class>항목을 명시 적으로 추가해야합니다 . 같은 다른 파일 이름을 사용하여 항목 이 필요 하지 않게하고 해당 파일을 일반 파일 과 동일한 폴더에 넣을 수 있습니다. 테스트 폴더의 Spring 컨텍스트는를 참조 할 수 있으며 Spring은 .persistence.xmljava.lang.IllegalArgumentException: Not an entity: class ...<class>persistence-TEST.xmlpersistence.xml<property name="persistenceXmlLocation" value="META-INF/persistence-TEST.xml" />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>
여러 persistence.xml 파일이 JPA의 일반적인 문제이며 클래스 로딩 트릭으로 만 해결되는 것 같습니다.
나를 위해 작동하는 해결 방법은 하나의 persistence.xml 파일에 여러 지속성 단위를 정의한 다음 배포 및 테스트 코드가 다른 바인딩을 사용하는지 확인하는 것입니다 (Spring에서는 엔티티 관리자 팩토리에서 "persistenceUnitName"속성을 설정할 수 있음). 테스트 구성으로 배포 파일을 오염 시키지만 제대로 작동하는지 신경 쓰지 않는다면.
테스트를 위해 persistance.xml을 추가하십시오. /src/test/resources/META-INF/persistence.xml@Arjan이 말했듯이 지속성 유닛의 루트를 변경 하고 엔티티 클래스는 target / test-classes에서 스캔됩니다. 이를 처리하려면 이 persistance.xml에 jar-file 요소를 추가하십시오 .
/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 파일뿐 아니라 디렉토리를 대상으로 할 수 있기 때문에 작동 합니다.
ClassLoaderProxy 접근 방식을 시도했지만 JPA 주석이 달린 클래스가 최대 절전 모드에서 영구 클래스로 처리되지 않는다는 문제가있었습니다.
그래서 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를 확장하고 TestCase.setup ()에서 setup ()을 호출합니다.
유일한 단점은 지속적 클래스를 최신 상태로 유지하는 것입니다. 그러나 JUnit 테스트의 경우 이것은 저에게 허용됩니다.
Rich Seller 게시물 로 테스트 및 제작을 위해 다른 persistence.xml을 사용하는 솔루션을 선호합니다 (감사합니다 !!).
하지만 변경해야합니다.
<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 파일에 포함되지 않도록하기 위해
persistence.xml 파일의 두 사본을 보관하십시오. 하나는 테스트 용이고 다른 하나는 일반 빌드 용입니다.
기본 라이프 사이클은 빌드 persistence.xml을 src / test / resources / META-INF에 복사합니다.
실행할 때 테스트 persistence.xml을 src / test / resources / META-INF에 복사 할 별도의 프로필을 만듭니다.
모든 클래스를 명시 적으로 나열하고 추가하지 않는 한 Persistence.xml은 엔티티 클래스를 검색하기위한 시작점으로 사용됩니다. 따라서이 파일을 다른 파일 (예 : src / test / resources)로 재정의하려면이 두 번째 persistence.xml에서 모든 단일 엔티티 클래스를 지정해야합니다. 그렇지 않으면 엔티티 클래스를 찾을 수 없습니다.
또 다른 해결책은 maven-resources-plugin ( 'copy-resources'목표)을 사용하여 파일을 덮어 쓰는 것입니다. 그러나 테스트를 위해 한 번 (예 : 단계 프로세스 테스트 클래스)과 실제 패키징 (단계 '패키지 준비')을 위해 한 번씩 두 번 덮어 써야합니다.
이 대답은 어리석은 것처럼 들릴 수 있지만 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에 복사하고 있습니다. 작동합니다.
저도 똑같은 일을하려고합니다. 저에게 맞는 솔루션이 있습니다. 귀하의 솔루션은 다를 수 있습니다 (솔루션이 마음에 들지 않을 수도 있습니다 ... 약간 낮은 수준입니다).
나는 그들이 영감을주는 비슷한 일을하기 위해 커스텀 클래스 로더를 사용하는 인터넷 기사를 보았습니다. 누구든지 개선 방법을 볼 수 있다면 제안을 환영합니다 btw. 배포를 위해 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");
}
}
}
이것을 조금 더 설명하기 위해 :
- 두 개의 persistence.xml 파일이 있습니다 (하나는 테스트 외부에서 사용되는 persistence.xml이고 다른 하나는 테스트에 사용되는 test-persist.xml).
- 사용자 정의 클래스 로더는 단위 테스트 에서만 활성화됩니다 (배포의 경우 모든 것이 정상 임).
- 사용자 정의 클래스 로더는 "META-INF / persistence.xml"에 대한 요청을 테스트 버전 ( "META-INF / test-persist.xml")으로 리디렉션합니다.
Hibernate가 Hibernate를로드하는 데 사용 된 클래스 로더로 (어떻게 든) 되돌릴 것이기 때문에 원래 몇 가지 문제에 부딪 혔습니다 (적어도 그게 진행되고 있다고 생각합니다). ClassLoader 전환 코드 (첫 번째 블록)를 테스트 케이스에 정적 블록으로 넣으면 Hibernate 전에로드되지만 단위 테스트 구조에 따라 다른 위치에 동일한 코드를 넣어야 할 수도 있음을 발견했습니다. (왝).
또 다른 접근 방식은 테스트를 위해 별도의 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;
}
}
OpenEJB를 사용할 때 persistence.xml을 대체 설명 자로 재정의 할 수 있습니다 . http://tomee.apache.org/alternate-descriptors.html
이것은 클래스 경로에서 여러 persistence.xml 파일을 찾는 Hibernate를 적절하게 처리하고 상태 복원을 사전 테스트하는 Rich Seller의 답변의 확장입니다.
설정:
배포 / 패키징을위한 하나의 지속성 파일과 테스트를위한 하나의 지속성 파일을 만듭니다.
src / main / resources / persistence.xml
src / test / resources / persistence- .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 % 복원됩니다. 남은 파일 없음
이 사용 사례에 대한 또 다른 옵션은 여러 지속성 단위를 추가하는 것입니다. 하나는 프로덕션을위한 것이고 다른 하나는 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;
}
}
persistence.xml을 사용하여 자체 Maven 프로젝트에 테스트를 넣습니다.
database.proprerties 파일을 필터링하고 프로필 당 하나의 database.properties를 가질 수있는 다른 maven 프로필을 사용하는 것이 좋습니다.
이렇게하면 .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>
With the help of surefire for unit tests and failsfe for integration tests, you're done.
<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>
Now you need just mvn test for your unit tests and mvn verify -Pintegration for your integration tests. Obviously you should create the database.properties files in the specified (on the profiles) paths (or elsewhere and change the paths)
Based-on reference: http://www.petrikainulainen.net/programming/tips-and-tricks/creating-profile-specific-configuration-files-with-maven/
참고URL : https://stackoverflow.com/questions/385532/how-to-configure-jpa-for-testing-in-maven
'Programing' 카테고리의 다른 글
| C ++ 17, C ++ 14 및 C ++ 11 개체를 연결하는 것이 안전합니까? (0) | 2020.11.12 |
|---|---|
| Assert.Fail ()은 나쁜 습관으로 간주됩니까? (0) | 2020.11.12 |
| DBCC CHECKIDENT는 ID를 0으로 설정합니다. (0) | 2020.11.12 |
| Sqlalchemy-for 루프에서 query와 query.all의 차이점 (0) | 2020.11.12 |
| 내장 모듈과 이름이 같은 모듈을 가져 오려고하면 가져 오기 오류가 발생합니다. (0) | 2020.11.12 |