Les tests JUnit réussissent dans Eclipse mais échouent dans Maven Surefire
J'ai écrit des tests JUnit à l'aide de JUnit 4 et de bibliothèques de tests de printemps. Lorsque je lance les tests à l'intérieur d'Eclipse, je vais bien et réussir. Mais lorsque je les exécute avec Maven (pendant le processus de construction), ils échouent en donnant une erreur liée à un ressort. Je ne suis pas sûr de ce qui cause le problème, JUnit, Surefire ou Spring. Voici mon code de test, la configuration du ressort et l'exception que je reçois 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 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.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
J'ai eu le même problème (les tests JUnit ont échoué dans Maven Surefire mais réussi dans Eclipse) et j'ai réussi à le résoudre en définissant forkMode sur 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> toujours </ forkMode> </ configuration> </ plugin>
Paramètres Surefire: http://maven.Apache.org/plugins/maven-surefire-plugin/test-mojo.html
Éditer (janvier 2014):
Comme Peter Perháč a souligné, le paramètre forkMode est obsolète 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 Fork et exécution de tests parallèles
J'ai eu un problème similaire, l'annotation @Autowired dans le code de test ne fonctionnait pas avec la ligne de commande Maven alors que cela fonctionnait bien dans Eclipse. Je viens de mettre à jour ma version de 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 soudainement rencontré cette erreur et la solution pour moi consistait à désactiver l'exécution de tests en parallèle.
Votre kilométrage peut varier, car je pourrais réduire le nombre de tests ayant échoué en configurant surefire pour exécuter des tests en parallèle par "classes":
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.7.2</version>
<configuration>
<parallel>classes</parallel>
<threadCount>10</threadCount>
</configuration>
</plugin>
Comme je l'ai écrit en premier, cela ne suffisait pas pour ma suite de tests. J'ai donc complètement désactivé le mode parallèle en supprimant le <configuration> section.
J'ai le même problème, mais avec IntelliJ IDEA + + Maven + TestNG + test de printemps. (test de ressort est essentiel bien sûr :)) J'ai changé la configuration de maven-surefire-plugin pour désactiver les tests en parallèle. Comme ça:
<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'avais la même chose: des tests qui allaient passer dans Eclipse ont échoué lorsque l'objectif de test de Maven a été exécuté.
Il s’est avéré être un test antérieur dans ma suite, dans un autre package. Cela m'a pris une semaine à résoudre!
Un test précédent testait certaines classes Logback et créait un contexte Logback à partir d'un fichier de configuration.
Le dernier test testait une sous-classe de SimpleRestTemplate de Spring et, d'une manière ou d'une autre, le contexte précédent de Logback était conservé, avec DEBUG activé. Cela a entraîné des appels supplémentaires dans RestTemplate pour enregistrer HttpStatus, etc.
C'est une autre chose de vérifier si on se retrouve jamais dans cette situation. J'ai résolu mon problème en injectant des Mocks dans ma classe de test Logback, de sorte qu'aucun contexte réel de Logback n'ait été créé.
J'avais le même problème, mais le problème pour moi était que Java (par exemple, assert (num> 0)) n'étaient pas activées pour Eclipse, mais étaient activées lors de l'exécution de maven.
Par conséquent, l’exécution des tests jUnit à partir d’Eclipse n’a pas intercepté l’erreur d’assertion.
Ceci est clairement expliqué lors de l’utilisation de jUnit 4.11 (par opposition à la version précédente que j’utilisais) car il affiche l’erreur d’assertion, 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)
J'ai eu un problème similaire avec une cause différente et donc une solution différente. Dans mon cas, une erreur s'est produite lors de la modification d'une variable membre d'un objet singleton d'une manière non threadsafe. Dans ce cas, suivre les réponses acceptées et contourner le test parallèle ne ferait que masquer l’erreur révélée par le test. Bien entendu, ma solution consiste à corriger la conception afin que mon code ne comporte pas ce mauvais comportement.
Résultat d'exécution de test différent de JUnit run et de maven install semble être le symptôme de plusieurs problèmes.
La désactivation de l'exécution du test de réutilisation de thread a également permis d'éliminer le symptôme dans notre cas, mais l'impression que le code n'était pas thread-safe était toujours forte.
Dans notre cas, la différence était due à la présence d'un haricot modifiant le comportement du test. Exécuter uniquement le test JUnit donnerait de bons résultats, mais l’exécution du projet install cible entraînerait l’échec du scénario de test. Comme c'était le cas test en cours de développement, il était immédiatement suspect.
Il en résulta qu'un autre cas de test instanciait un haricot via Spring qui survivrait jusqu'à l'exécution du nouveau cas de test. La présence du bean modifiait le comportement de certaines classes et produisait le résultat manquant.
La solution dans notre cas était de se débarrasser du haricot, qui n'était pas nécessaire au départ (encore un autre prix de l'arme copier + coller).
Je suggère à tout le monde avec ce symptôme de rechercher quelle est la cause première. Désactiver la réutilisation des threads dans l'exécution du test peut uniquement le masquer.
[Je ne suis pas sûr qu'il s'agisse d'une réponse à la question initiale, car le tracé de pile est légèrement différent, mais il peut être utile à d'autres.]
Si vous exécutez également Cobertura (pour obtenir des rapports de couverture de code), les tests peuvent échouer dans Surefire. En effet, Cobertura nécessite des mandataires (pour mesurer l'utilisation de code) et il existe un conflit entre ces mandataires et ceux de Spring. Ceci niquement se produit lorsque Spring utilise cglib2, ce qui serait le cas si, par exemple, vous avez proxy-target-class="true", ou si vous avez un objet soumis à la proxy qui n'implémente pas les interfaces.
Le correctif habituel consiste à ajouter une interface. Ainsi, par exemple, les DAO doivent être des interfaces, implémentées par une classe DAOImpl. Si vous connectez automatiquement sur l'interface, tout fonctionnera correctement (car cglib2 n'est plus nécessaire; vous pouvez utiliser un proxy JDK plus simple pour l'interface et Cobertura fonctionnera correctement avec cela).
Cependant, vous ne pouvez pas utiliser d'interfaces avec des contrôleurs annotés (vous obtiendrez une erreur d'exécution lorsque vous tenterez d'utiliser le contrôleur dans une servlet). Je n'ai pas de solution pour les tests Cobertura + Spring utilisant des contrôleurs autowire.
J'ai eu un problème similaire: les tests JUnit ont échoué dans Maven Surefire mais ont été transmis dans Eclipse lorsque j'ai utilisé la version 4.11.0 de la bibliothèque JUnit à partir du référentiel SpringSource Bundle. Particulary:
<dependency>
<groupId>org.junit</groupId>
<artifactId>com.springsource.org.junit</artifactId>
<version>4.11.0</version>
</dependency>
Ensuite, je l'ai remplacée par la suivante version 4.11 de la bibliothèque JUnit et tout fonctionne bien.
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
</dependency>
J'ai eu ce problème aujourd'hui en testant une méthode qui convertissait un objet contenant un Map en une chaîne JSON. Je suppose que Eclipse et le plug-in Maven Surefire utilisaient différents JRE qui implémentaient différentes commandes de HashMap, ou quelque chose du genre, ce qui entraînait l'échec des tests via Eclipse et l'échec des tests avec surefire (assertEquals échoué). La solution la plus simple consistait à utiliser une implémentation de Map dotée d'un système de commande fiable.
Cela m'a aidé à résoudre mon problème. J'ai eu des symptômes similaires en ce que Maven échouerait, mais l'exécution des tests Junit se passe bien.
Il se trouve que mon parent pom.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 le remplace pour supprimer 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 le plugin surefire.
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 bocaux locaux. J'ai utilisé Maven pour les dépendances en ligne et configuré manuellement le chemin de génération pour les dépendances locales. Maven n'était donc pas au courant des dépendances configurées manuellement.
J'ai utilisé cette solution pour installer les dépendances de jar locales dans Maven:
Comment ajouter des fichiers jar locaux dans le projet maven?
Vous n'avez pas besoin d'injecter une source de données dans JpaTransactionManager car EntityManagerFactory possède déjà une source de données. Essayez ce qui suit:
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>
Habituellement, lorsque les tests passent dans Eclipse et échouent avec maven, il s'agit d'un problème de chemin de classe, car il s'agit de la principale différence entre les deux.
Vous pouvez donc vérifier le chemin de classe avec maven -X test et vérifier le chemin de classe d’Eclipse via les menus ou dans le fichier .classpath situé à la racine de votre projet.
Etes-vous sûr, par exemple, que personservice-test.xml est dans le classpath?