wake-up-neo.com

JUnit-Tests bestehen in Eclipse, schlagen aber in Maven Surefire fehl

Ich habe einige JUnit-Tests mit JUnit 4 und Spring-Test-Bibliotheken geschrieben. Wenn ich die Tests in Eclipse durchführe, laufen sie einwandfrei und bestehen. Wenn ich sie jedoch mit Maven (während des Erstellungsprozesses) ausführe, wird kein Fehler im Zusammenhang mit der Feder ausgegeben. Ich bin nicht sicher, was das Problem verursacht, JUnit, Surefire oder Spring. Hier ist mein Testcode, die Federkonfiguration und die Ausnahme, die ich von Maven bekomme:

PersonServiceTest.Java

package com.xyz.person.test;

import static com.xyz.person.util.FjUtil.toFjList;
import static junit.framework.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;

import Java.util.List;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.AbstractTransactionalJUnit4SpringContextTests;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.transaction.TransactionConfiguration;
import org.springframework.transaction.annotation.Transactional;

import com.xyz.person.bo.Person;
import com.xyz.person.bs.PersonService;

import fj.Effect;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = { "classpath*:personservice-test.xml" })
@TransactionConfiguration(transactionManager = "transactionManager", defaultRollback = false)
public class PersonServiceTest {

    @Autowired
    private PersonService service;

    @Test
    @Transactional
    public void testCreatePerson() {
        Person person = new Person();
        person.setName("abhinav");
        service.createPerson(person);

        assertNotNull(person.getId());
    }

    @Test
    @Transactional
    public void testFindPersons() {
        Person person = new Person();
        person.setName("abhinav");
        service.createPerson(person);

        List<Person> persons = service.findPersons("abhinav");
        toFjList(persons).foreach(new Effect<Person>() {
            public void e(final Person p) {
                assertEquals("abhinav", p.getName());
            }});
    }

}

personservice-test.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans.xsd
      http://www.springframework.org/schema/tx
      http://www.springframework.org/schema/tx/spring-tx.xsd
      http://www.springframework.org/schema/aop
      http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
      http://www.springframework.org/schema/context
      http://www.springframework.org/schema/context/spring-context-2.5.xsd">

    <import resource="classpath:/personservice.xml" />

    <bean id="datasource"
        class="org.springframework.jdbc.datasource.DriverManagerDataSource"
        lazy-init="true">
        <property name="driverClassName" value="org.Apache.derby.jdbc.EmbeddedDriver" />
        <property name="url" value="jdbc:derby:InMemoryDatabase;create=true" />
    </bean>

    <bean id="entityManagerFactory"
        class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
        <property name="dataSource" ref="datasource" />
        <property name="persistenceUnitName" value="PersonService" />
        <property name="jpaVendorAdapter">
            <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
                <property name="databasePlatform" value="org.hibernate.dialect.DerbyDialect" />
                <property name="showSql" value="true" />
                <property name="generateDdl" value="true" />
            </bean>
        </property>
        <property name="jpaPropertyMap">
            <map>
                <entry key="hibernate.validator.autoregister_listeners" value="false" />
                <entry key="javax.persistence.transactionType" value="RESOURCE_LOCAL" />
            </map>
        </property>
    </bean>

    <bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
        <property name="entityManagerFactory" ref="entityManagerFactory" />
        <property name="dataSource" ref="datasource" />
    </bean>

    <tx:annotation-driven transaction-manager="transactionManager"
        proxy-target-class="false" />

    <bean id="beanMapper" class="org.dozer.DozerBeanMapper">
        <property name="mappingFiles">
            <list>
                <value>personservice-mappings.xml</value>
            </list>
        </property>
    </bean>

</beans>

Ausnahme in Maven

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running com.xyz.person.test.PersonServiceTest
23:18:51,250  WARN JDBCExceptionReporter:77 - SQL Warning: 10000, SQLState: 01J01
23:18:51,281  WARN JDBCExceptionReporter:78 - Database 'InMemoryDatabase' not created, connection made to existing database instead.
23:18:52,937  WARN JDBCExceptionReporter:77 - SQL Warning: 10000, SQLState: 01J01
23:18:52,937  WARN JDBCExceptionReporter:78 - Database 'InMemoryDatabase' not created, connection made to existing database instead.
23:18:52,953  WARN TestContextManager:429 - Caught exception while allowing TestExecutionListener [org.springframew[email protected]359a359a] to process 'after' execution for test: method [public void com.xyz.person.test.PersonServiceTest.testCreatePerson()], instance [[email protected]], exception [org.springframework.transaction.IllegalTransactionStateException: Pre-bound JDBC Connection found! JpaTransactionManager does not support running within DataSourceTransactionManager if told to manage the DataSource itself. It is recommended to use a single JpaTransactionManager for all transactions on a single DataSource, no matter whether JPA or JDBC access.]
Java.lang.IllegalStateException: No value for key [org[email protected]3f563f56] bound to thread [main]
        at org.springframework.transaction.support.TransactionSynchronizationManager.unbindResource(TransactionSynchronizationManager.Java:199)
        at org.springframework.orm.jpa.JpaTransactionManager.doCleanupAfterCompletion(JpaTransactionManager.Java:489)
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.cleanupAfterCompletion(AbstractPlatformTransactionManager.Java:1011)
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.Java:804)
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.Java:723)
        at org.springframework.test.context.transaction.TransactionalTestExecutionListener$TransactionContext.endTransaction(TransactionalTestExecutionListener.Java:515)
        at org.springframework.test.context.transaction.TransactionalTestExecutionListener.endTransaction(TransactionalTestExecutionListener.Java:290)
        at org.springframework.test.context.transaction.TransactionalTestExecutionListener.afterTestMethod(TransactionalTestExecutionListener.Java:183)
        at org.springframework.test.context.TestContextManager.afterTestMethod(TestContextManager.Java:426)
        at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.Java:90)
        at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.Java:72)
        at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.Java:240)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.Java:50)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.Java:193)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.Java:52)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.Java:191)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.Java:42)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.Java:184)
        at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.Java:61)
        at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.Java:70)
        at org.junit.runners.ParentRunner.run(ParentRunner.Java:236)
        at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.Java:180)
        at org.Apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.Java:59)
        at org.Apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.Java:115)
        at org.Apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.Java:102)
        at org.Apache.maven.surefire.Surefire.run(Surefire.Java:180)
        at Sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at Sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.Java:39)
        at Sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.Java:37)
        at Java.lang.reflect.Method.invoke(Method.Java:599)
        at org.Apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.Java:350)
        at org.Apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.Java:1021)
23:18:53,078  WARN TestContextManager:377 - Caught exception while allowing TestExecutionListener [org.springframew[email protected]359a359a] to process 'before' execution of test method [public void com.xyz.person.test.PersonServiceTest.testFindPersons()] for test instance [[email protected]]
org.springframework.transaction.IllegalTransactionStateException: Pre-bound JDBC Connection found! JpaTransactionManager does not support running within DataSourceTransactionManager if told to manage the DataSource itself. It is recommended to use a single JpaTransactionManager for all transactions on a single DataSource, no matter whether JPA or JDBC access.
        at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.Java:304)
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.Java:371)
        at org.springframework.test.context.transaction.TransactionalTestExecutionListener$TransactionContext.startTransaction(TransactionalTestExecutionListener.Java:507)
        at org.springframework.test.context.transaction.TransactionalTestExecutionListener.startNewTransaction(TransactionalTestExecutionListener.Java:269)
        at org.springframework.test.context.transaction.TransactionalTestExecutionListener.beforeTestMethod(TransactionalTestExecutionListener.Java:162)
        at org.springframework.test.context.TestContextManager.beforeTestMethod(TestContextManager.Java:374)
        at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.Java:73)
        at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.Java:82)
        at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.Java:72)
        at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.Java:240)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.Java:50)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.Java:193)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.Java:52)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.Java:191)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.Java:42)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.Java:184)
        at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.Java:61)
        at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.Java:70)
        at org.junit.runners.ParentRunner.run(ParentRunner.Java:236)
        at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.Java:180)
        at org.Apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.Java:59)
        at org.Apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.Java:115)
        at org.Apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.Java:102)
        at org.Apache.maven.surefire.Surefire.run(Surefire.Java:180)
        at Sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at Sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.Java:39)
        at Sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.Java:37)
        at Java.lang.reflect.Method.invoke(Method.Java:599)
        at org.Apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.Java:350)
        at org.Apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.Java:1021)
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 15.625 sec <<< FAILURE!

Results :

Tests in error:
  testCreatePerson(com.xyz.person.test.PersonServiceTest)
  testCreatePerson(com.xyz.person.test.PersonServiceTest)
  testFindPersons(com.xyz.person.test.PersonServiceTest)

Tests run: 3, Failures: 0, Errors: 3, Skipped: 0
82
Abhinav Sarkar

Ich hatte das gleiche Problem (JUnit-Tests in Maven Surefire fehlgeschlagen, aber in Eclipse bestanden) und konnte es lösen, indem ich forkMode auf immer in der Maven-todsicheren Konfiguration in pom.xml:

 <plugin> 
 <groupId> org.Apache.maven.plugins </ groupId> 
 <artifactId> maven-surefire-plugin </ artifactId> 
 < version> 2.12 </ version> 
 <configuration> 
 <forkMode> always </ forkMode> 
 </ configuration> 
 </ plugin> 

Surefire-Parameter: http://maven.Apache.org/plugins/maven-surefire-plugin/test-mojo.html

Bearbeiten (Januar 2014):

Wie Peter Perháč hervorhob, ist der forkMode-Parameter seit Surefire 2.14 veraltet. Ab Surefire 2.14 verwenden Sie stattdessen Folgendes:

<plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.16</version>
    <configuration>
        <reuseForks>false</reuseForks>
        <forkCount>1</forkCount>
    </configuration>
</plugin>

Weitere Informationen finden Sie unter Gabeloptionen und parallele Testausführung

91
simon

Ich hatte ein ähnliches Problem, die Anmerkung @Autowired im Testcode funktionierte unter Verwendung der Maven-Befehlszeile nicht, während es in Eclipse einwandfrei funktionierte. Ich habe gerade meine JUnit-Version von 4.4 auf 4.9 aktualisiert und das Problem wurde behoben.

<dependency>
    <groupId>junit</groupId
    <artifactId>junit</artifactId>
    <version>4.9</version>
</dependency>
7
cartman1989

Ich hatte plötzlich diesen Fehler und die Lösung bestand darin, die parallele Ausführung von Tests zu deaktivieren.

Ihre Laufleistung kann variieren, da ich die Anzahl der fehlgeschlagenen Tests verringern könnte, indem ich surefire so konfiguriere, dass parallele Tests nach "Klassen" durchgeführt werden:

            <plugin>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.7.2</version>
                <configuration>
                    <parallel>classes</parallel>
                    <threadCount>10</threadCount>
                </configuration>
            </plugin>

Wie ich zuerst schrieb, reichte dies für meine Testsuite nicht aus, so dass ich die Parallele vollständig deaktivierte, indem ich den Abschnitt <configuration> Entfernte.

7

Ich habe das ähnliche Problem, aber mit IntelliJ IDEA + Maven + TestNG + Federtest. (Federtest ist natürlich unerlässlich :)) Es wurde behoben, wann Ich habe die Konfiguration von maven-surefire-plugin geändert, um parallele Tests zu deaktivieren. So was:

<plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.9</version>
    <configuration>
        <skipTests>${maven.test.skip}</skipTests>
        <trimStackTrace>false</trimStackTrace>
        <!--<parallel>methods</parallel>-->
        <!-- to skip integration tests -->
        <excludes>
            <exclude>**/IT*Test.Java</exclude>
            <exclude>**/integration/*Test.Java</exclude>
        </excludes>
    </configuration>
    <executions>
        <execution>
            <id>integration-test</id>
            <phase>integration-test</phase>
            <goals>
                <goal>test</goal>
            </goals>
            <configuration>
                <skipTests>${maven.integration-test.skip}</skipTests>
                <!-- Make sure to include this part, since otherwise it is excluding Integration tests -->
                <excludes>
                    <exclude>none</exclude>
                </excludes>
                <includes>
                    <include>**/IT*Test.Java</include>
                    <include>**/integration/*Test.Java</include>
                </includes>
            </configuration>
        </execution>
    </executions>
</plugin>
5
s13o

Dies trifft nicht genau auf Ihre Situation zu, aber ich hatte das Gleiche - Tests, die in Eclipse bestanden wurden, schlugen fehl, wenn das Testziel von Maven ausgeführt wurde.

Es stellte sich heraus, dass es sich in meiner Suite bereits um einen Test handelte, in einem anderen Paket. Ich habe eine Woche gebraucht, um es zu lösen!

Ein früherer Test testete einige Logback-Klassen und erstellte einen Logback-Kontext aus einer Konfigurationsdatei.

Der spätere Test testete eine Unterklasse von Spring's SimpleRestTemplate und irgendwie wurde der frühere Logback-Kontext mit DEBUG aufrechterhalten. Dies führte dazu, dass zusätzliche Aufrufe in RestTemplate vorgenommen wurden, um HttpStatus usw. zu protokollieren.

Es ist eine andere Sache zu überprüfen, ob man jemals in diese Situation gerät. Ich habe mein Problem behoben, indem ich einige Mocks in meine Logback-Testklasse eingefügt habe, sodass keine echten Logback-Kontexte erstellt wurden.

5
Jim Jarrett

Ich hatte das gleiche Problem, aber das Problem für mich war, dass Java) Zusicherungen (z. B. assert (num> 0)) nicht für Eclipse aktiviert waren, sondern beim Ausführen von maven aktiviert wurden.

Daher hat das Ausführen der jUnit-Tests in Eclipse den Assertionsfehler nicht ausgelöst.

Dies wird bei Verwendung von jUnit 4.11 deutlich (im Gegensatz zu der älteren Version, die ich verwendet habe), da der Assertionsfehler ausgegeben wird, z.

Java.lang.AssertionError: null
    at com.company.sdk.components.schema.views.impl.InputViewHandler.<init>(InputViewHandler.Java:26)
    at test.com.company.sdk.util.TestSchemaExtractor$MockInputViewHandler.<init>(TestSchemaExtractor.Java:31)
    at test.com.company.sdk.util.TestSchemaExtractor.testCreateViewToFieldsMap(TestSchemaExtractor.Java:48)
3
Ryan

Ich hatte ein ähnliches Problem mit einer anderen Ursache und damit einer anderen Lösung. In meinem Fall trat tatsächlich ein Fehler auf, bei dem für ein Singleton-Objekt eine Member-Variable nicht threadsicher geändert wurde. In diesem Fall würde das Befolgen der akzeptierten Antworten und das Umgehen des Paralleltests nur den Fehler verbergen, der tatsächlich durch den Test aufgedeckt wurde. Meine Lösung besteht natürlich darin, das Design so zu korrigieren, dass ich dieses schlechte Verhalten in meinem Code nicht habe.

3
Brick

Das Ergebnis der Testausführung unterscheidet sich von JUnit run und von maven install scheint ein Symptom für mehrere Probleme zu sein.

Das Deaktivieren der Testausführung zur Wiederverwendung von Threads hat in unserem Fall ebenfalls das Symptom beseitigt, aber der Eindruck, dass der Code nicht thread-sicher war, war immer noch stark.

In unserem Fall war der Unterschied auf das Vorhandensein einer Bohne zurückzuführen, die das Testverhalten veränderte. Das Ausführen nur des JUnit-Tests würde zu einem guten Ergebnis führen, das Ausführen des Ziels project install würde jedoch zu einem fehlgeschlagenen Testfall führen. Da es sich um den in der Entwicklung befindlichen Testfall handelte, war er sofort verdächtig.

Es ergab sich, dass ein anderer Testfall eine Bean durch Spring instanziierte, die bis zur Ausführung des neuen Testfalls überlebte. Die Bean-Präsenz veränderte das Verhalten einiger Klassen und führte zu dem fehlgeschlagenen Ergebnis.

Die Lösung in unserem Fall war, die Bohne loszuwerden, die überhaupt nicht benötigt wurde (ein weiterer Preis aus der copy + paste gun).

Ich schlage jedem mit diesem Symptom vor, die Ursache zu untersuchen. Wenn Sie die Thread-Wiederverwendung in der Testausführung deaktivieren, wird sie möglicherweise nur ausgeblendet.

3
manuelvigarcia

[Ich bin mir nicht sicher, ob dies eine Antwort auf die ursprüngliche Frage ist, da die Stapelspur hier etwas anders aussieht, aber für andere nützlich sein kann.]

In Surefire können Tests fehlschlagen, wenn Sie Cobertura ausführen (um Berichte zur Codeabdeckung abzurufen). Dies liegt daran, dass Cobertura Proxies benötigt (um die Verwendung von Code zu messen) und es eine Art Konflikt zwischen diesen und Spring-Proxies gibt. Dies nur tritt auf, wenn Spring cglib2 verwendet, was der Fall wäre, wenn Sie zum Beispiel proxy-target-class="true", oder wenn Sie ein Objekt haben, das als Proxy fungiert und keine Schnittstellen implementiert.

Die normale Lösung besteht darin, eine Schnittstelle hinzuzufügen. So sollten DAOs beispielsweise Schnittstellen sein, die von einer DAOImpl-Klasse implementiert werden. Wenn Sie auf der Schnittstelle automatisch verdrahten, funktioniert alles einwandfrei (da cglib2 nicht mehr benötigt wird; stattdessen kann ein einfacherer JDK-Proxy für die Schnittstelle verwendet werden, und Cobertura funktioniert einwandfrei).

Sie können jedoch keine Schnittstellen mit kommentierten Controllern verwenden (es wird ein Laufzeitfehler angezeigt, wenn Sie versuchen, den Controller in einem Servlet zu verwenden). Ich habe keine Lösung für Cobertura + Spring-Tests, bei denen Controller automatisch verkabelt werden.

2
andrew cooke

Ich hatte ein ähnliches Problem: JUnit-Tests sind in Maven Surefire fehlgeschlagen, wurden jedoch in Eclipse bestanden, als ich die JUnit-Bibliotheksversion 4.11.0 aus dem SpringSource Bundle Repository verwendete. Insbesondere:

<dependency>
    <groupId>org.junit</groupId>
    <artifactId>com.springsource.org.junit</artifactId>
    <version>4.11.0</version>
</dependency>

Dann habe ich es mit der folgenden JUnit-Bibliothek Version 4.11 ersetzt und alles funktioniert einwandfrei.

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.11</version>
</dependency>
2
Lukas Risko

Ich hatte heute dieses Problem beim Testen einer Methode, die ein Objekt, das Map enthielt, in eine JSON-Zeichenfolge konvertierte. Ich gehe davon aus, dass Eclipse und das todsichere Maven-Plugin unterschiedliche JREs verwendeten, die unterschiedliche Implementierungen von HashMap ordering aufwiesen, was dazu führte, dass die durch Eclipse ausgeführten Tests bestanden und die durch todsichere ausgeführten Tests fehlschlugen (assertEquals gescheitert). Die einfachste Lösung bestand darin, eine Implementierung von Map zu verwenden, die eine zuverlässige Bestellung hatte.

1
Mitch

Dies hat mir bei der Behebung meines Problems geholfen. Ich hatte ein ähnliches Symptom in diesem Maven, aber das Ausführen von Junit-Tests funktioniert einwandfrei.

Wie sich herausstellt, enthält meine übergeordnete Datei pom.xml die folgende Definition:

    <plugin>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>2.9</version>
      <configuration>
        <forkMode>pertest</forkMode>
        <argLine>-Xverify:none</argLine>
      </configuration>
    </plugin>

Und in meinem Projekt überschreibe ich es, um die argLine zu entfernen:

    <plugin>
       <artifactId>maven-surefire-plugin</artifactId>
       <configuration>
            <forkMode>pertest</forkMode>
            <argLine combine.self="override"></argLine>
          </configuration>
    </plugin>

Hoffentlich hilft dies jemandem bei der Fehlersuche im todsicheren Plugin.

0
mmastika

Ich hatte das gleiche Problem und die Lösung für mich bestand darin, Maven zu erlauben, alle Abhängigkeiten zu verarbeiten, auch zu lokalen Gläsern. Ich habe Maven für Online-Abhängigkeiten verwendet und den Erstellungspfad für lokale Abhängigkeiten manuell konfiguriert. Daher war Maven nicht über die Abhängigkeiten informiert, die ich manuell konfiguriert habe.

Ich habe diese Lösung verwendet, um die lokalen JAR-Abhängigkeiten in Maven zu installieren:

Wie füge ich lokale JAR-Dateien in maven project hinzu?

0
Bitango.me

Sie müssen keine DataSource in den JpaTransactionManager einfügen, da die EntityManagerFactory bereits über eine Datenquelle verfügt. Versuche Folgendes:

<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
   <property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>
0

Normalerweise ist es ein Klassenpfadproblem, wenn Tests in Eclipse erfolgreich sind und mit maven fehlschlagen, da dies der Hauptunterschied zwischen beiden ist.

So können Sie den Klassenpfad mit maven -X test überprüfen und den Klassenpfad von Eclipse über die Menüs oder in der .classpath-Datei im Stammverzeichnis Ihres Projekts überprüfen.

Sind Sie zum Beispiel sicher, dass sich die Datei personservice-test.xml im Klassenpfad befindet?

0
Bruno Thomas