I am trying to replace JMock with Mockito (1.10.17). I have already done some unit tests successfully, but now I want to use the timeout feature
verify(publisher, timeout(5000)).notifySubscribers(any(BecameMasterMessage.class));
and I get this exception:
java.lang.VerifyError: (class: org/mockito/internal/verification/VerificationOverTimeImpl, method: verify signature: (Lorg/mockito/internal/verification/api/VerificationData;)V) Incompatible argument to function
at org.mockito.verification.Timeout.<init>(Timeout.java:32)
at org.mockito.verification.Timeout.<init>(Timeout.java:25)
at org.mockito.Mockito.timeout(Mockito.java:2164)
The issue happens in IntelliJ and with Maven. There is only 1 version of Mockito on the classpath. There is also JMock 2.5.1 on the classpath which I cannot remove since 99% of my unit tests still use JMock at this moment. I don't know if that has anything to do with it.
UPDATE: I tried with JMock 2.6.0 and Hamcrest 1.3 but the result is the same.
UPDATE 2:
This works:
Thread.sleep( 5000 );
verify( m_publisher ).notifySubscribers( any( BecameMasterMessage.class ) );
And this does not:
verify(publisher, timeout(5000)).notifySubscribers(any(BecameMasterMessage.class));
UPDATE 3:
I have made a small test project that has the exact same problem: See https://github.com/wimdeblauwe/mockito-verify-problem and run it from IntelliJ or with Maven.
The problem here is an unfortunate constellation between TestNG, JUnit and Mockto. To fix your issue, you just need to add a dependency to JUnit 4.0 or greater (the most recent version is currently 4.12):
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
</dependency>
Here are the details:
TestNG, which is apparently your testing framework, declares a dependency to the quite old JUnit version 3.8.1. Mockito does not declare a dependency to JUnit at all but it uses some JUnit classes that were introduced in JUnit 4.0 (!).
Edit:
The method Mockito#timeout() in your example creates a Timeout instance which in turn creates an instance of VerificationOverTimeImpl. The method VerificationOverTimeImpl#verify() handles an error of type ArgumentsAreDifferent which is a subclass of org.junit.ComparisonFailure.
From JUnit version 3.8.1 to 4.x the class hierarchy of ComparisonFailure changed to having AssertionError instead of Error as base class. The VerifiyError is caused because VerificationOverTimeImpl#handleVerifyException() requires an AssertionError but would be invoked with an Error when JUnit 3.8.1 is used.
EDIT: It seems stefan answered first. His diagnostic is almost correct, however, org.mockito.exceptions.verification.junit.ArgumentsAreDifferent do extends junit.framework.ComparisonFailure, that is present in JUnit 3.x and it is a dependency of TestNG 5.x.
The VerifyError itself has probably something to do when the JVM is performing the linking as there is changes in the ComparisonFailure type itself between JUnit 3.x and JUnit 4.x.
Anyway the issue in Mockito is that it uses a JUnit class where it shouldn't. And that Mockito don't support anymore JUnit 3.x.
tl;tr
We have an issue in the code internally the verification mode you are using use a JUnit class, that is not on the classpath. Adding JUnit in the dependency of your POM will fix things.
Thanks for reporting. I've created an issue on GitHub (#152)
long story
For some reason TestNG 5.xxx make the JVM fail with a VerifyError, on a method that is not even called at that point.
java.lang.VerifyError: (class: org/mockito/internal/verification/VerificationOverTimeImpl, method: verify signature:
(Lorg/mockito/internal/verification/api/VerificationData;)V) Incompatible argument to function
But switching to the latest version of TestNG, 6.8.something make the JVM fail with an understandable cause : NoClassDefFoundError
java.lang.NoClassDefFoundError: junit/framework/ComparisonFailure
Which points to the real issue here, now there's only to find which class depends on JUnit. This class is ArgumentsAreDifferent which extends junit.framework.ComparisonFailure, this exception appears in a try/catch block in VerificationOverTimeImpl that is needed for the timeout verification.
This issue has been there probably since 1.10.x when fixing some timeout issues.
Note I copied this answer on the mailing list as well.
Related
I'm using JUnit 5 in my Spring project and would like to do some mocking using Mockito. So I've I added a couple Mockito dependencies: mockito-core 2.21.0 and mockito-junit-jupiter 4.0.0.
Then based on some guidance I found somewhere I added this to my very simple test class:
#ExtendWith(MockitoExtension.class)
But when I run the test I get this confounding error:
java.lang.NoSuchMethodError: org.mockito.internal.configuration.plugins.Plugins.
getMockitoLogger()Lorg/mockito/plugins/MockitoLogger;
...
But I'm not using the MockitoLogger class anywhere, or at least not explicitly. So what could cause this strangeness?
If you want to mock a method and test a method in the same class you have to use #Spy instead of #Mock. Then you should remove the #BeforeEach code block. Additionally you have to call the method you want to test.
Plz share more code, thanks
I'm upgrading my code from Java v1.8 to v11.0.8. All went fine until I run the tests mvn test and Mockito starts having issues. Every test errors-out.
My versions of Mockito are fine (2.23.4) according to other answers here so I go to run just 1 test to narrow down the problem - it runs fine. So I run all the tests by right-clicking in Eclipse on my src/test/java and choosing Run As > JUnit test. Again, all run fine.
Note: I hesitate to add the error message here because the code works (as noted above), so this can be a distraction, but this question got a close request for lack of error message!
You are seeing this disclaimer because Mockito is configured to create inlined mocks.
You can learn more about inline mocks and their limitations under #39 of the Mockito class javadoc
Underlying exception: org.mockito.exceptions.base.MockitoException: Could not modify all classes [..., ..., ...]
at ...
at ...
Caused by org.springframework.beans.BeanInstantiationException: Failed to instantiate [..]: Factory method '...' threw exception; nested exception is org.springframework.beans.BeanCreationException: Error creating bean with name '...' defined in...
Mockito cannot mock this class: ...
If you're not sure why you're getting this error, please report to the mailing list.
The app itself runs fine with springboot:run clean
My tests always ran with only test as the goal, that is confirmed for me here, so what's changed?
I also see references to: Bytebuddy in that article but I have a good version of that too (1.9.16)
I now want to add junit benchmark to my alreadyexisting junit testclasses.I use junit 4.10.I added junit benchmark 0.7.2. When I try running a testclass, it shows java.lang.Exception: Field benchmarkRun must implement MethodRule. How to fix this? I thought junit 4.10 would have MethodRule as deprecated.
For me it is working fine with JUnit4.11. I had to delete com.springsource.org.junit-4.7.0.jar from the classpath. So please make sure you do not have any old versions of Junit related jars in your class path.
I am using Google Guava v13.0 but when I run a JUnit test with code containing tryFind, I get this message:
java.lang.NoSuchMethodError: com.google.common.collect.Iterables.tryFind(Ljava/lang/Iterable;Lcom/google/common/base/Predicate;)Lcom/google/common/base/Optional;
This only seems to happen with JUnit tests as when the production code runs there are no problems. I am using Intellij IDEA v11.1.3 and can navigate into the guava JAR file to find tryFind in the com.google.common.collect.Iterable.class.
I've seen similar posts, but I'm not sure how this relates to JUnit. Any ideas on what my issue might be?
This sort of error is usually caused by having an older version of Guava (or even google-collections) on the classpath in addition to the newer version you're trying to use. Try to check what's on the classpath when running your test.
Go with Colin's answer, here's a nice way to detect where the stuff is loaded:
System.out.println(
Iterables.class.getProtectionDomain().getCodeSource().getLocation()
);
This should print out the path to the guava (or g-c) version you are using.
I've been coding tests in Junit4 with Spring, and I got this funny behavior:
If my tests are passing like this, everything is fine:
#Test
public void truthTest(){
assertTrue(true); //Ok
}
But, if my test fails:
#Test
public void truthTest(){
assertTrue(false); //ERROR
}
Then instead of a test failure I receive an ugly and cryptic stack trace, This is it:
http://pastie.org/429912
Sorry for this ugly dump, but its the only data I've got to explain the problem (I "pastied" it for readability)
I'm really puzzled, has anyone encountered this kind of problem before? Thanks in advance!
http://jira.springframework.org/browse/SPR-5145
It is an known issue with spring-test 2.5.x. It is incompatible with JUnit 4.5. Use 4.0-4.4.
Or you can try the patch in the issue tracker.
I had the same problem when I wrote my Spring JUnit tests. Like a lot of posts available online, there are only two alternatives
1) Stay up to date with the Spring version and use the latest version of JUnit
or
2) Leave your current Spring version and use JUnit version 4.4 or less.
I chose the option # 2 where we left our Spring version at 2.5 and downloaded JUnit 4.4. Everything worked fine after that.
Also another point to be aware of is that if your project i.e., the project A you are writing your tests in has a dependency on another project B that has another version of Spring, you would get a similar error too. I learnt it the hard way.
-Prashanth
What if you imported AssumptionViolatedException into your test class?
It looks like it can't find the class to throw the appropriate exception.