I have written some JUnit tests using JUnit 4 and spring-test libraries. When I run the tests inside Eclipse then run fine and pass. But when I run them using Maven (during
It is most likely that your configuration files are in src/main/resources, while they must be under src/test/resources to work properly under maven.
https://cwiki.apache.org/UIMA/differences-between-running-unit-tests-in-eclipse-and-in-maven.html
I'm replying this after two years 'cause I couldn't find this answer here and I think it is the right one.
I had a similar problem with a different cause and therefore different solution. In my case, I actually had an error where a singleton object was having a member variable modified in a non-threadsafe way. In this case, following the accepted answers and circumventing the parallel testing would only hide the error that was actually revealed by the test. My solution, of course, is to fix the design so that I don't have this bad behavior in my code.
I had the same issue, but the problem for me was that Java assertions (e.g. assert(num > 0)) were not enabled for Eclipse, but were enabled when running maven.
Therefore running the jUnit tests from Eclipse did not catch trigger the assertion error.
This is made clear when using jUnit 4.11 (as opposed to the older version I was using) because it prints out the assertion error, e.g.
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)
Test execution result different from JUnit run
and from maven install
seems to be symptom for several problems.
Disabling thread reusing test execution did also get rid of the symptom in our case, but the impression that the code was not thread-safe was still strong.
In our case the difference was due to the presence of a bean that modified the test behaviour. Running just the JUnit test would result fine, but running the project install
target would result in a failed test case. Since it was the test case under development, it was immediately suspicious.
It resulted that another test case was instantiating a bean through Spring that would survive until the execution of the new test case. The bean presence was modifying the behaviour of some classes and producing the failed result.
The solution in our case was getting rid of the bean, which was not needed in the first place (yet another prize from the copy+paste gun).
I suggest everybody with this symptom to investigate what the root cause is. Disabling thread reuse in test execution might only hide it.
I had a similar problem, the annotation @Autowired
in the test code did not work under using the Maven command line while it worked fine in Eclipse. I just update my JUnit version from 4.4 to 4.9 and the problem was solved.
<dependency>
<groupId>junit</groupId
<artifactId>junit</artifactId>
<version>4.9</version>
</dependency>
Usually when tests pass in eclipse and fail with maven it is a classpath issue because it is the main difference between the two.
So you can check the classpath with maven -X test and check the classpath of eclipse via the menus or in the .classpath file in the root of your project.
Are you sure for example that personservice-test.xml is in the classpath ?