How to use findToString method of org.mockito.internal.matchers.MatchersToStringTest 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>

Update July 29, 2015 by @durron597: This excellent answer was correct in 2013, however it has since been rendered obsolete by an update to Mockito. See this answer.

I use latest JUnit with Mockito core dependency and hamcrest 1.3 in many Maven projects at work. Till now nobody reported any problem with this. So if this works for your tests go with the newest Version for all three. Just ensure to use mockito core instead of all.

So I would recommend to go with option 2 to have all benefits of the newer versions. If you are really in doubt that anything could go wrong use option 4 which is the safest one. But of course you could go with option 2 and when in the near future anything would be wrong you could switch to option 2. Or since then a newer mockito is already out there solving this.

Note from mockito Issue 397: This problem does not appear with mockito-core.

I think

Mockito.reset(wareHouseSpy)

would do it.

The two syntaxes for stubbing are roughly equivalent. However, you can always use doReturn/when for stubbing; but there are cases where you can't use when/thenReturn. Stubbing void methods is one such. Others include use with Mockito spies, and stubbing the same method more than once.

One thing that when/thenReturn gives you, that doReturn/when doesn't, is type-checking of the value that you're returning, at compile time. However, I believe this is of almost no value - if you've got the type wrong, you'll find out as soon as you run your test.

I strongly recommend only using doReturn/when. There is no point in learning two syntaxes when one will do.

You may wish to refer to my answer at Forming Mockito "grammars" - a more detailed answer to a very closely related question.

I think it should be

verify(mockBar, times(2)).doSomething(...)

Sample from mockito javadoc:

ArgumentCaptor<Person> peopleCaptor = ArgumentCaptor.forClass(Person.class);
verify(mock, times(2)).doSomething(peopleCaptor.capture());

List<Person> capturedPeople = peopleCaptor.getAllValues();
assertEquals("John", capturedPeople.get(0).getName());
assertEquals("Jane", capturedPeople.get(1).getName());

Inlining code can sometimes be confusing. Let's unwrap the second block of code:

A source = mock(A.class);
final List<String> documents = getList();
final Iterator<String> iter = getList().iterator()
when(source.iterator()).thenReturn(iter);

Now, it's easier to understand. The same iter object is always returned, and hence it retains it's state. The fact that before the change above mockito had a function call in the brackets is inconsequential - mockito has an object passed to it, which it stores internally, and returns when required. It cannot "remember" that this object was produced by calling a function unless it has the actual code to execute it - for example, like you did in the first snippet.

The sample works if you remove the PowerMock dependencies. The issue is that the versions of Mockito and PowerMock used are incompatible with each other. For PowerMock 2.x you need at least Mockito 2.8.9+. PowerMock provides a compatibility list that shows what version of PowerMock is compatible with what version of Mockito. Fix up the versions to be compatible with each other and your sample will start to work.

Try the thenAnswer instead of thenReturn:

Answer<Stream> answer = new Answer<Stream>() {
    public Stream answer(InvocationOnMock invocation) throws Throwable {
        return Stream.of("A", "B");
    }
};


when(mock.streamMethod()).thenAnswer(answer);

Now a new Stream will be created for each call to streamMethod.

Further read:

Here is an article I wrote on Dynamic Answering in Mockito that might be complementary.

Actually they are technically the same. When Mockito was first created, we were talking about stubs, so the vocabulary followed that idea. Later people thought it was better to think in interactions rather that technical terms, so the vocabulary followed the when ... then ... style. This change in vocabulary helps people to think about interactions, messaging between object. Which is the most interesting idea (message passing) thing in an object oriented language (quoting Alan Kay).

Nowadays testing approach has evolved to Behavior Driven Development (from Dan North), which is almost the same thing but focus even more on the behavior at design time. To reflect that thinking, people asked Mockito to offer an API that reflect that change. So you also use given ... will ... style from BDDMockito

given(the_type.performs_that()).willReturn(something)

This is my preferred vocabulary now as I use tests to drive my objects design.