Les tests de JUnit sont réussis dans Eclipse mais échouent dans Maven Surefire
j'ai écrit quelques tests JUnit en utilisant les bibliothèques JUnit 4 et spring-test. Quand je fais les tests à L'intérieur D'Eclipse, je m'en sors bien et je réussis. Mais quand je les exécute en utilisant Maven (pendant le processus de construction), ils échouent en donnant une erreur liée au ressort. Je ne sais pas ce qui cause le problème, JUnit, Surefire ou Spring. Voici mon code de test, la configuration du ressort et l'exception que J'obtiens de 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());
}});
}
}
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>
Exception dans 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.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access"151920920"0(ParentRunner.java:42)
at org.junit.runners.ParentRunner.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.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access"151920920"0(ParentRunner.java:42)
at org.junit.runners.ParentRunner.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
16 réponses
j'ai eu le même problème (les tests de JUnit ont échoué dans Maven Surefire mais ont réussi dans Eclipse) et j'ai réussi à le résoudre en réglant forkMode à toujours dans la configuration de maven surefire dans pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12</version>
<configuration>
<forkMode>always</forkMode>
</configuration>
</plugin>
paramètres Surefire: http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html
Edit (Janvier 2014):
comme Peter Perháč fait remarquer, le paramètre forkMode est déprécié depuis Surefire 2.14. À partir de Surefire 2.14 utilisez ceci à la place:
<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>
pour plus d'informations, voir Options de fourche et exécution des essais en parallèle
j'ai subitement ressenti cette erreur, et la solution pour moi était de désactiver les tests en parallèle.
votre milage peut varier, puisque je pourrais réduire le nombre de tests échoués en configurant surefire pour exécuter des tests parallèles par classes.:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.7.2</version>
<configuration>
<parallel>classes</parallel>
<threadCount>10</threadCount>
</configuration>
</plugin>
comme j'ai écrit en premier, ce n'était pas suffisant pour ma suite de test, donc j'ai complètement désactivé parallèle en supprimant la section <configuration> .
j'ai eu un problème similaire, l'annotation @Autowired dans le code de test ne fonctionnait pas en utilisant la ligne de commande Maven alors qu'elle fonctionnait bien dans Eclipse. Je viens de mettre à jour ma version JUnit de 4.4 à 4.9 et le problème a été résolu.
<dependency>
<groupId>junit</groupId
<artifactId>junit</artifactId>
<version>4.9</version>
</dependency>
j'ai le même problème,mais avec IntelliJ IDEA + Maven + TestNG + spring-test. ( printemps-test est essentiel, bien sûr :) ) Il a été corrigé lorsque j'ai changé la config de maven-surefire-plugin pour désactiver les tests d'exécution en parallèle. Comme ceci:
<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>
cela ne s'applique pas exactement à votre situation, mais j'ai eu la même chose -- les tests qui passeraient en Eclipse ont échoué quand le but du test de Maven a été effectué.
il s'est avéré être un test plus tôt dans ma suite, dans un paquet différent . Ça m'a pris une semaine à résoudre!
un test antérieur testait quelques classes de Logback, et créait un contexte de Logback à partir d'un fichier de configuration.
le dernier test était tester une sous-classe du SimpleRestTemplate de Spring, et d'une manière ou d'une autre, le contexte de Logback antérieur a été tenu, avec DEBUG on. Cela a provoqué des appels supplémentaires dans RestTemplate pour log HttpStatus,etc.
c'est une autre chose de vérifier si quelqu'un se retrouve dans cette situation. J'ai résolu mon problème en injectant des moqueries dans ma classe de test de Logback, de sorte qu'aucun contexte de Logback réel n'a été créé.
j'ai eu le même problème, mais le problème pour moi était que les assertions Java (e.g. assert(num > 0)) n'étaient pas activées pour Eclipse, mais étaient activées lors de l'exécution maven.
donc exécuter les tests de jUnit à partir D'Eclipse n'a pas déclenché l'erreur d'assertion.
cela est précisé lors de l'utilisation de jUnit 4.11 (par opposition à l'ancienne version que j'utilisais) parce qu'il imprime l'erreur d'affirmation, par exemple
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)
[Je ne suis pas sûr que ce soit une réponse à la question originale, puisque la stactrace ici semble légèrement différente, mais il peut être utile à d'autres.]
vous pouvez obtenir des tests échouant dans Surefire lorsque vous utilisez également Cobertura (pour obtenir des rapports de couverture de code). Cela est dû au fait que Cobertura a besoin de mandataires (pour mesurer l'utilisation du code) et qu'il y a une sorte de conflit entre ces mandataires et les mandataires de ressort. Ce seulement se produit lorsque le printemps utilise cglib2, ce qui serait le cas si, par exemple, vous avez proxy-target-class="true" , ou si vous avez un objet proxy qui n'est pas d'implémenter des interfaces.
le correctif normal est d'ajouter une interface. Ainsi, par exemple, DAOs devrait être une interface, implémentée par une classe DAOImpl. Si vous autorisez l'interface, tout va bien se passer (parce que cglib2 n'est plus nécessaire; un simple proxy JDK vers l'interface peut être utilisé à la place et Cobertura fonctionne très bien avec ce.)
cependant, vous ne pouvez pas utiliser d'interfaces avec des contrôleurs annotés (vous obtiendrez une erreur d'exécution lorsque vous essayez d'utiliser le contrôleur dans un servlet) - Je n'ai pas de solution pour les tests de ressort de Cobertura + que les contrôleurs autowire.
j'ai eu un problème similaire: les tests de JUnit ont échoué dans Maven Surefire mais ont réussi dans Eclipse quand j'ai utilisé la version 4.11.0 de la bibliothèque JUnit du dépôt SpringSource Bundle. Particulier:
<dependency>
<groupId>org.junit</groupId>
<artifactId>com.springsource.org.junit</artifactId>
<version>4.11.0</version>
</dependency>
puis je l'ai remplacé par la version 4.11 de la bibliothèque JUnit et tout fonctionne très bien.
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
</dependency>
j'ai eu ce problème aujourd'hui tester une méthode qui a converti un objet qui contenait un Map à une chaîne JSON. Je suppose Qu'Eclipse et le plugin Maven surefire utilisaient des JREs différents qui avaient des implémentations différentes de HashMap ou quelque chose, ce qui a fait que les tests exécutés à travers Eclipse ont réussi et que les tests exécutés à travers surefire ont échoué ( assertEquals a échoué). La solution la plus simple était d'utiliser une implémentation de Map qui avait une commande fiable.
j'ai eu un problème similaire avec une cause différente et donc une solution différente. Dans mon cas, j'ai en fait eu une erreur où un objet singleton avait une variable membre modifiée d'une manière non-threadsafe. Dans ce cas, le fait de suivre les réponses acceptées et de contourner le test parallèle ne ferait que masquer l'erreur réellement révélée par le test. Ma solution, bien sûr, est de réparer le design pour que je n'ai pas ce mauvais comportement dans mon code.
vous n'avez pas besoin d'injecter une source de données dans le JpaTransactionManager car EntityManagerFactory dispose déjà d'une source de données. Essayez ce qui suit:
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>
généralement, lorsque les tests passent dans eclipse et échouent avec maven, c'est un problème de classepath parce que c'est la principale différence entre les deux.
pour que vous puissiez vérifier la classpath avec maven-X test et vérifier la classpath d'eclipse via les menus ou dans le .classpath fichier dans la racine de votre projet.
Êtes-vous sûr par exemple que personservice-test.xml est dans classpath ?
cela m'a aidé à résoudre mon problème. J'avais des symptômes similaires dans le fait que maven ne réussirait pas, cependant exécuter des tests junit fonctionne très bien.
comme il s'avère que mon parent pom.le xml contient la définition suivante:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.9</version>
<configuration>
<forkMode>pertest</forkMode>
<argLine>-Xverify:none</argLine>
</configuration>
</plugin>
et dans mon projet je l'outrepasse pour enlever l'argLine:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>pertest</forkMode>
<argLine combine.self="override"></argLine>
</configuration>
</plugin>
espérons que cela aidera quelqu'un à résoudre surefire plugin.
j'ai eu le même problème, et la solution pour moi était de permettre à Maven de gérer toutes les dépendances, y compris les pots locaux. J'ai utilisé Maven pour les dépendances en ligne, et configuré le chemin de compilation manuellement pour les dépendances locales. Maven n'était donc pas au courant des dépendances que j'avais configurées manuellement.
j'ai utilisé cette solution pour installer les dépendances locales jar dans Maven:
le résultat d'exécution du Test différent de JUnit run et de maven install semble être le symptôme de plusieurs problèmes.
désactiver la réutilisation de thread l'exécution de test a également éliminé le symptôme dans notre cas, mais l'impression que le code n'était pas thread-safe était encore forte.
dans notre cas, la différence était due à la présence d'un haricot qui modifiait le comportement d'essai. Exécuter juste le test de JUnit serait très bien, mais exécuter le la cible du projet install se solderait par un échec. Comme il s'agissait du cas d'essai en cours d'élaboration, il était immédiatement suspect.
il en est résulté qu'un autre cas d'essai instanciait un haricot à travers le ressort qui survivrait jusqu'à l'exécution du nouveau cas d'essai. La présence du haricot modifiait le comportement de certaines classes et produisait le résultat raté.
La solution dans notre cas, était de se débarrasser de la fève, qui n'était pas nécessaire en premier lieu (encore un autre prix du copier+coller gun).
je suggère à tous ceux qui ont ce symptôme d'étudier la cause profonde. Désactiver la réutilisation de thread dans l'exécution des tests ne peut que le cacher.
il est très probable que vos fichiers de configuration se trouvent dans src/main/resources , alors qu'ils doivent se trouver sous src/test/resources pour fonctionner correctement sous maven.
https://cwiki.apache.org/UIMA/differences-between-running-unit-tests-in-eclipse-and-in-maven.html
je réponds après deux ans parce que je n'ai pas pu trouver cette réponse ici et je pense que c'est la bonne un.