How to use shouldReportArgumentsAreDifferent method of org.mockito.internal.verification.checkers.MissingInvocationInOrderCheckerTest class

You should check out the exec-maven-plugin.

With the following configuration (notice the <systemProperties>)...

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>1.3.2</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>java</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <mainClass>com.example.Main</mainClass>
        <arguments>
            <argument>argument1</argument>
        </arguments>
        <systemProperties>
            <systemProperty>
                <key>hello.world</key>
                <value>Hello Stack Overflow!</value>
            </systemProperty>
        </systemProperties>
    </configuration>
</plugin>

...and the following class...

package com.example;
public class Main {
    public static void main(String[] args) {
        String prop = System.getProperty("hello.world");
        System.out.println(prop);
    }
}

...and running a package (notice the phase in the configuration - you can change if you want, maybe to install), it prints out the value Hello Stack Overflow! from the key hello.world. So basically, the plugin executes your program when you build.

See also the exec:exec goal. In the example, I used the exec:java goal, but the two are different in how they function.

exec:exec executes programs and Java programs in a separate process.

exec:java executes Java programs in the same VM.

UPDATE

Currently I am setting some values in properties based on the profile in my maven pom file. Is it possible to set this system property in the profile ? because really, i only have one pom file for dev and prod and its within the profile i would need to set it.

Yes, just use the ${property.name} in the <value> element of the system property element. For example:

<profiles>
    <profile>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <id>world</id>
        <properties>
            <hello.world>Hello World!</hello.world>
        </properties>
    </profile>
    <profile>
        <activation>
            <activeByDefault>false</activeByDefault>
        </activation>
        <id>stack</id>
        <properties>
            <hello.world>Hello Stack Overflow</hello.world>
        </properties>
    </profile>
</profiles>

And the plugin <systemProperties>:

<systemProperties>
    <systemProperty>
        <key>hello.world</key>
        <value>${hello.world}</value>
    </systemProperty>
</systemProperties>

Just by changing the profile, to either stack or world, the message will print Hello Stack Overflow or Hello World, respectively.

UPDATE 2

Another plugin is the properties-maven-plugin. Nothing's been done on it in a while, but from a few tests, the necessary functionality is there.

It has a set-system-properties goal along with some other useful goals to help ease properties management

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>properties-maven-plugin</artifactId>
    <version>1.0-alpha-2</version>
    <executions>
        <execution>
            <!-- any phase before your app deploys -->
            <phase>prepare-package</phase>
            <goals>
                <goal>set-system-properties</goal>
            </goals>
            <configuration>
                <properties>
                    <property>
                        <name>hello.world.two</name>
                        <value>Hello World!</value>
                    </property>
                </properties>
            </configuration>
        </execution>
    </executions>
</plugin>

It sounds like you may want to be using the .expects(1) type methods that mock frameworks usually provide.

Using mockito, if you were testing a List and wanted to verify that clear was called 3 times and add was called at least once with these parameters you do the following:

List mock = mock(List.class);        
someCodeThatInteractsWithMock();                 

verify(mock, times(3)).clear();
verify(mock, atLeastOnce()).add(anyObject());      

Source - MockitoVsEasyMock

This question might be old but since this was the nearest answer I found when I had this problem I though I'd describe my solution.

Using JUnit 4

Split your tests up so that there is one test method per class (this solution only changes classloaders between classes, not between methods as the parent runner gathers all the methods once per class)

Add the @RunWith(SeparateClassloaderTestRunner.class) annotation to your test classes.

Create the SeparateClassloaderTestRunner to look like this:

public class SeparateClassloaderTestRunner extends BlockJUnit4ClassRunner {

    public SeparateClassloaderTestRunner(Class<?> clazz) throws InitializationError {
        super(getFromTestClassloader(clazz));
    }

    private static Class<?> getFromTestClassloader(Class<?> clazz) throws InitializationError {
        try {
            ClassLoader testClassLoader = new TestClassLoader();
            return Class.forName(clazz.getName(), true, testClassLoader);
        } catch (ClassNotFoundException e) {
            throw new InitializationError(e);
        }
    }

    public static class TestClassLoader extends URLClassLoader {
        public TestClassLoader() {
            super(((URLClassLoader)getSystemClassLoader()).getURLs());
        }

        @Override
        public Class<?> loadClass(String name) throws ClassNotFoundException {
            if (name.startsWith("org.mypackages.")) {
                return super.findClass(name);
            }
            return super.loadClass(name);
        }
    }
}

Note I had to do this to test code running in a legacy framework which I couldn't change. Given the choice I'd reduce the use of statics and/or put test hooks in to allow the system to be reset. It may not be pretty but it allows me to test an awful lot of code that would be difficult otherwise.

Also this solution breaks anything else that relies on classloading tricks such as Mockito.

Although not a direct answer to your question, however I suggest that you move away from field injection and use constructor injection instead (makes code more readable and testable).

Your code would look like:

class Patient {

  private final Syringe syringe;

  @Inject
  public Patient(Syringe syringe) {
    System.out.println("That hurt like crazy!");
  }

}

Then your test would simply be:

@RunWith(MockitoJUnitRunner.class)
class TestCase {

  @Mock
  Syringe siringeMock;

  Patient patient;

  @Before
  public void setup() {
     patient = new Patient(siringeMock);
  }

}

Update

As suggested by Erik-Karl in the comments, you could use @InjectMocks to get rid of the setup method. The solution works because Mockito will use the appropriate constructor injection (as described here). The code would then look like:

@RunWith(MockitoJUnitRunner.class)
class TestCase {

  @Mock
  Syringe siringeMock;

  @InjectMocks
  Patient patient;

}

How about

when( method-call ).thenReturn( value1, value2, value3 );

You can put as many arguments as you like in the brackets of thenReturn, provided they're all the correct type. The first value will be returned the first time the method is called, then the second answer, and so on. The last value will be returned repeatedly once all the other values are used up.

Mockito comes with a helper class to save you some reflection boiler plate code:

import org.mockito.internal.util.reflection.Whitebox;

//...

@Mock
private Person mockedPerson;
private Test underTest;

// ...

@Test
public void testMethod() {
    Whitebox.setInternalState(underTest, "person", mockedPerson);
    // ...
}

Update: Unfortunately the mockito team decided to remove the class in Mockito 2. So you are back to writing your own reflection boilerplate code, use another library (e.g. Apache Commons Lang), or simply pilfer the Whitebox class (it is MIT licensed).

Update 2: JUnit 5 comes with its own ReflectionSupport and AnnotationSupport classes that might be useful and save you from pulling in yet another library.

I've finally been able to solve my problem. The key to the answer is the line

java.lang.IllegalStateException: Could not self-attach to current VM using external process

For Java 9 and more, one must add -Djdk.attach.allowAttachSelf=true as VM argument to avoid this exception. When I did, unit tests ran perfectly.

Here are the links where I've found this :

https://github.com/raphw/byte-buddy/issues/612

https://github.com/mockk/mockk/issues/254

Just point that with Mockito you can also use AdditionalMatchers and ArgumentMatchers

import static org.mockito.AdditionalMatchers.not;
import static org.mockito.ArgumentMatchers.eq;

//anything but not "ejb"    
mock.someMethod(not(eq("ejb")));

According its documentation:

Example of using logical and(), not(), or() matchers:

//anything but not "ejb"
mock.someMethod(not(eq("ejb")));

There is more info in this other SO question

Hope it helps

I've needed this several times as well. I've put together a small sample below, which you'd want to adjust to your needs. Basically, you create your own Appender and add it to the logger you want. If you'd want to collect everything, the root logger is a good place to start, but you can use a more specific if you'd like. Don't forget to remove the Appender when you're done, otherwise you might create a memory leak. Below I've done it within the test, but setUp or @Before and tearDown or @After might be better places, depending on your needs.

Also, the implementation below collects everything in a List in memory. If you're logging a lot you might consider adding a filter to drop boring entries, or to write the log to a temporary file on disk (Hint: LoggingEvent is Serializable, so you should be able to just serialize the event objects, if your log message is.)

import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.apache.log4j.spi.LoggingEvent;
import org.junit.Test;

import java.util.ArrayList;
import java.util.List;

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

public class MyTest {
    @Test
    public void test() {
        final TestAppender appender = new TestAppender();
        final Logger logger = Logger.getRootLogger();
        logger.addAppender(appender);
        try {
            Logger.getLogger(MyTest.class).info("Test");
        }
        finally {
            logger.removeAppender(appender);
        }

        final List<LoggingEvent> log = appender.getLog();
        final LoggingEvent firstLogEntry = log.get(0);
        assertThat(firstLogEntry.getLevel(), is(Level.INFO));
        assertThat((String) firstLogEntry.getMessage(), is("Test"));
        assertThat(firstLogEntry.getLoggerName(), is("MyTest"));
    }
}

class TestAppender extends AppenderSkeleton {
    private final List<LoggingEvent> log = new ArrayList<LoggingEvent>();

    @Override
    public boolean requiresLayout() {
        return false;
    }

    @Override
    protected void append(final LoggingEvent loggingEvent) {
        log.add(loggingEvent);
    }

    @Override
    public void close() {
    }

    public List<LoggingEvent> getLog() {
        return new ArrayList<LoggingEvent>(log);
    }
}