Reported here: http://groups.google.com/group/mockito/t/d95e1b82d574a36f

Couldn't reproduce it along with instructions - see mockito-bug-1.zip attachment.

Here is what I am using. Remember that order of execution is essential to get this bug to happen.

Rundown of what is used:

Mockito 1.5 JUnit 3.8.1 Compiling/Source 1.5/1.5 JVM for execution 1.6 Ubuntu 8.0.4 Maven 2.0.6

I'll be happy to answer any other questions.

I'm trying it out

I ran several times from the command line:

mvn clean test -Dtest=ObjectOneTest,ObjectTwoTest

and (different order of tests):

mvn clean test -Dtest=ObjectTwoTest,ObjectOneTest

It's working fine in the following environment: Windows XP (the only true OS...) Maven 2.0.9 Sun's java 1.6.0_06

I'm downgrading maven now...

It's working fine with maven 2.0.6 :( I'm gonna ask someone with Ubuntu to try it out.

Are you running it from command line as I wrote before? Maybe surfire plugin is messed up in your place... Can you purge your m2 repo?

I'm seeing this sort of thing when running tests under eclipse as a plugin unit test. It only occurs for verifyZeroInteractions and verifyNoMoreInteractions calls. (Similar to to the bleeder test case).

I've attached an adapted bleeder test case that uses PDE to run the tests.

Note that you need an Eclipse 3.4 install with PDE (plugin development environment installed). The Classic (http://www.eclipse.org/downloads/packages/compare-packages) package DOES have PDE installed.

Platform: Windows XP SP3 Java 1.6.0_07 Eclipse 3.4 w/ PDE

To run: * Extract the zip file to a temporary location (c:\temp) * Load eclipse (with a new workspace if possible) * From eclipse, choose File -> Import -> Existing project into workspace * Choose Select root directory and enter c:\temp\bleedertest-pde * Select bleedertest-pde and click Finish * Navigate to bleedertest-pde.

To Run the tests in an order that passes (ObjectOneTest then ObjectTwoTest) * Navigate to PassesTests.launch in the root of the project directory (package view) * Right click on PassesTests.launch * Click Run As -> PassesTests

Expected Result: All tests pass Actual Result: All tests pass

To run tests in an order that fails: (ObjectTwoTest then ObjectOneTest) * Navigate to FailsTests.launch in the root of the project directory (package view) * Right click on FailsTests.launch * Click Run As -> FailsTests Expected Result: All tests pass

Actual Result: org.mockito.exceptions.verification.NoInteractionsWanted: No interactions wanted at com.odintechnologies.ObjectOneTest.testInput(ObjectOneTest.java:23) Caused by: org.mockito.exceptions.cause.UndesiredInvocation: Undesired invocation: dependentObject.getData( "this is the test string" ); at com.odintechnologies.ObjectTwo.finish(ObjectTwo.java:17) at com.odintechnologies.ObjectTwoTest.testOne(ObjectTwoTest.java:25) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:574) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:195) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212)

The only difference between the two launchers is that the associated test suite runs the tests in a different order.

I'm trying it right now.

BTW. Do you experience those problems after upgrade from mockito 1.x -> 1.5 ?

I'm unable to reproduce the bug marc.d.champan reported.

I run the test case with the following configuration mixture: *Ubuntu 8.0.4 *Maven 2.0.6 and Maven 2.0.9 *JDKs: 1.6.0_05 / 1.6.0_06 / 1.6.0_07

I have also renamed the test to enforce different order.

Everything works fine.

Should have said I'm using mockito-all-1.5.jar

Good news :) I'm able to reproduce the problem with acambrell's setup.

I'm glad that someone was able to reproduce this. I was able to also fix the problem by moving to a new version of junit (I had specified 3.8 before).

Wow, interesting that upgrading junit helped out.

I found the problem and fixed it in the trunk, if interested see r914

If you want to upgrade trunk version then please note that trunk introduces some modifications to the API

Thanks a lot for supplying nice zip with an easy way to reproduce the bug!

This issue was closed by revision 443620111b.