I test di JUnit vengono superati in Eclipse ma falliscono in Maven Surefire

Ho scritto alcuni test JUnit utilizzando JUnit 4 e le librerie di test di primavera. Quando eseguo i test all'interno di Eclipse, corro bene e passo. Ma quando li eseguo usando Maven (durante il processo di compilazione), falliscono dando un errore relativo alla molla. Non sono sicuro di cosa stia causando il problema, JUnit, Surefire o Spring. Ecco il mio codice di prova, la configurazione della molla e l'eccezione che ottengo da Maven:

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

}

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

Eccezione a 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.springframework.test.context.transaction.TransactionalTestExecutionListener@359a359a] to process 'after' execution for test: method [public void com.xyz.person.test.PersonServiceTest.testCreatePerson()], instance [com.xyz.person.test.PersonServiceTest@1bc81bc8], 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.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean@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.springframework.test.context.transaction.TransactionalTestExecutionListener@359a359a] to process 'before' execution of test method [public void com.xyz.person.test.PersonServiceTest.testFindPersons()] for test instance [com.xyz.person.test.PersonServiceTest@79f279f2]
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

Ho avuto lo stesso problema (i test JUnit non sono riusciti in Maven Surefire ma sono stati superati in Eclipse) e sono riuscito a risolverlo impostando forkMode su sempre nella configurazione maven surefire in pom.xml:

<plugin>
    <groupId> org.apache.maven.plugins </groupId>
    <artifactId> plugin-sicuro-infallibile </artifactId>
    <version> 2.12 </version>
    <configurazione>
        <forkMode> sempre </forkMode>
    </configuration>
</plugin>

Parametri Surefire: http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html

Modifica (gennaio 2014):

Come ha sottolineato Peter Perháč , il parametro forkMode è deprecato da Surefire 2.14. A partire da Surefire 2.14, usa invece questo:

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

Per ulteriori informazioni, vedere Opzioni fork ed esecuzione di test paralleli

Improvvisamente ho riscontrato questo errore e la soluzione per me è stata disabilitare per eseguire i test in parallelo.

Il tuo milage può variare, dal momento che potrei ridurre il numero di test falliti configurando surefire per eseguire test paralleli per "classi":

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

Come ho scritto prima, questo non era sufficiente per la mia suite di test, quindi ho disabilitato completamente il parallelismo rimuovendo la <configuration>sezione.

Ho avuto un problema simile, l'annotazione @Autowirednel codice di prova non funzionava utilizzando la riga di comando Maven mentre funzionava bene in Eclipse. Ho appena aggiornato la mia versione di JUnit dalla 4.4 alla 4.9 e il problema è stato risolto.

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

Questo non si applica esattamente alla tua situazione, ma ho avuto la stessa cosa: i test che sarebbero passati in Eclipse hanno fallito quando è stato eseguito l'obiettivo del test di Maven.

Si è rivelato essere un test in precedenza nella mia suite, in un pacchetto diverso . Mi ci è voluta una settimana per risolverlo!

Un test precedente stava testando alcune classi Logback e ha creato un contesto Logback da un file di configurazione.

Il test successivo stava testando una sottoclasse del SimpleRestTemplate di Spring e, in qualche modo, il contesto di logback precedente si è mantenuto, con DEBUG attivo. Ciò ha causato chiamate aggiuntive in RestTemplate per registrare HttpStatus, ecc.

Un'altra cosa è controllare se uno si trova mai in questa situazione. Ho risolto il mio problema iniettando alcuni mock nella mia classe di test Logback, in modo che non venissero creati contesti Logback reali.

Ho il problema simile, ma con IntelliJ IDEA + Maven + TestNG + spring-test. (Il test di primavera è essenziale ovviamente :)) È stato risolto quando ho cambiato la configurazione del plug-in maven-surefire per disabilitare l'esecuzione dei test in parallelo. Come questo:

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

Il risultato dell'esecuzione del test diverso da JUnit rune da maven installsembra essere sintomo di diversi problemi.

Anche la disabilitazione dell'esecuzione del test di riutilizzo dei thread ha eliminato il sintomo nel nostro caso, ma l'impressione che il codice non fosse thread-safe era ancora forte.

Nel nostro caso la differenza era dovuta alla presenza di un bean che modificava il comportamento del test. L'esecuzione del solo test JUnit risulterebbe corretta, ma l'esecuzione del installtarget del progetto risulterebbe in un test case fallito. Poiché era il test case in fase di sviluppo, è stato immediatamente sospetto.

Ne è risultato che un altro scenario di test stava creando un'istanza di un bean attraverso Spring che sarebbe sopravvissuto fino all'esecuzione del nuovo caso di test. La presenza del bean modificava il comportamento di alcune classi e produceva il risultato non riuscito.

La soluzione nel nostro caso è stata eliminare il fagiolo, che non era necessario in primo luogo (l'ennesimo premio della pistola copia + incolla ).

Suggerisco a tutti coloro che hanno questo sintomo di indagare su quale sia la causa principale. La disabilitazione del riutilizzo del thread nell'esecuzione del test potrebbe solo nasconderlo.

Ho avuto lo stesso problema, ma il problema per me era che le asserzioni Java (ad esempio assert (num> 0)) non erano abilitate per Eclipse, ma erano abilitate durante l'esecuzione di Maven.

Pertanto l'esecuzione dei test jUnit da Eclipse non ha rilevato il trigger dell'errore di asserzione.

Ciò è reso chiaro quando si utilizza jUnit 4.11 (al contrario della versione precedente che stavo usando) perché stampa l'errore di asserzione, ad es.

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)

Ho avuto un problema simile con una causa diversa e quindi una soluzione diversa. Nel mio caso, ho effettivamente avuto un errore in cui un oggetto singleton aveva una variabile membro modificata in modo non threadsafe. In questo caso, seguire le risposte accettate e aggirare il test parallelo nasconderebbe solo l'errore che è stato effettivamente rivelato dal test. La mia soluzione, ovviamente, è correggere il design in modo da non avere questo cattivo comportamento nel mio codice.

[Non sono sicuro che questa sia una risposta alla domanda originale, poiché lo stacktrace qui sembra leggermente diverso, ma potrebbe essere utile per gli altri.]

È possibile ottenere test con esito negativo in Surefire quando si esegue anche Cobertura (per ottenere rapporti sulla copertura del codice). Questo perché Cobertura richiede proxy (per misurare l'uso del codice) e c'è una sorta di conflitto tra questi e i proxy Spring. Ciò si verifica solo quando Spring utilizza cglib2, che sarebbe il caso, ad esempio, se lo si avesse proxy-target-class="true", o se si avesse un oggetto che viene sottoposto a proxy che non implementa le interfacce.

La soluzione normale a questo problema è aggiungere un'interfaccia. Quindi, ad esempio, i DAO dovrebbero essere interfacce, implementate da una classe DAOImpl. Se autowire sull'interfaccia, tutto funzionerà bene (perché cglib2 non è più richiesto; al suo posto può essere utilizzato un proxy JDK più semplice per l'interfaccia e Cobertura funziona bene con questo).

Tuttavia, non è possibile utilizzare interfacce con controller annotati (si riceverà un errore di runtime quando si tenta di utilizzare il controller in un servlet) - Non ho una soluzione per i test Cobertura + Spring che autowire i controller.

Ho avuto un problema simile: i test JUnit non sono riusciti in Maven Surefire ma sono stati superati in Eclipse quando ho utilizzato la versione 4.11.0 della libreria JUnit da SpringSource Bundle Repository. Particolare:

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

Quindi l'ho sostituito con la seguente versione della libreria JUnit 4.11 e tutto funziona correttamente.

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.11</version>
</dependency>

Ho avuto questo problema oggi testando un metodo che converte un oggetto che conteneva a Mapin una stringa JSON. Presumo che Eclipse e il plug-in Sicuri di Maven stessero utilizzando diversi JRE con diverse implementazioni di HashMapordinamento o qualcosa del genere, il che ha causato il superamento dei test eseguiti tramite Eclipse e il fallimento dei test eseguiti attraverso Sicuramente ( assertEqualsfallito). La soluzione più semplice era utilizzare un'implementazione di Map che avesse un ordinamento affidabile.

Non è necessario inserire un DataSource in JpaTransactionManager poiché EntityManagerFactory ha già un'origine dati. Prova quanto segue:

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

Di solito quando i test passano in eclipse e falliscono con Maven è un problema di classpath perché è la differenza principale tra i due.

Quindi puoi controllare il classpath con maven -X test e controllare il classpath di eclipse tramite i menu o nel file .classpath nella radice del tuo progetto.

Sei sicuro, ad esempio, che personservice-test.xml sia nel classpath?

Questo mi ha aiutato a risolvere il mio problema. Ho avuto sintomi simili in quanto Maven avrebbe fallito, tuttavia l'esecuzione di test junit funziona bene.

A quanto pare, il mio genitore pom.xml contiene la seguente definizione:

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

E nel mio progetto lo sovrascrivo per rimuovere argLine:

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

Si spera che questo aiuti qualcuno nella risoluzione dei problemi del plug-in infallibile.

Avevo lo stesso problema e la soluzione per me era consentire a Maven di gestire tutte le dipendenze, inclusi i jar locali. Ho usato Maven per le dipendenze online e ho configurato manualmente il percorso di compilazione per le dipendenze locali. Pertanto, Maven non era a conoscenza delle dipendenze che ho configurato manualmente.

Ho usato questa soluzione per installare le dipendenze jar locali in Maven:

Come aggiungere file jar locali nel progetto Maven?

Nel mio caso il motivo era un bug nel codice. Il test si basava su un certo ordine di elementi in a HashSet, che si è rivelato diverso se eseguito in Eclipse o in Maven Surefire.

È molto probabile che i tuoi file di configurazione siano in src / main / resources , mentre devono essere in src / test / resources per funzionare correttamente con maven.

https://cwiki.apache.org/UIMA/differences-between-running-unit-tests-in-eclipse-and-in-maven.html

Ti rispondo dopo due anni perché non sono riuscito a trovare questa risposta qui e penso che sia quella giusta.