How to use can_remove_a_collection method of org.mockito.internal.util.collections.HashCodeAndEqualsSafeSetTest class

Use statement like this before mocked object compareTo() method calling:

when(mockedObject.compareTo(any(Sortable.class))).thenCallRealMethod();

A good technique for getting rid of static calls on 3rd party API is hiding the static call behind an interface.

Let's say you make this interface :

interface IPDOFacade {

    IPDO getContextPDO();
}

and have a default implementation that simply calls the static method on the 3rd party API :

class IPDOFacadeImpl implements IPDOFacade {

    @Override
    public IPDO getContextPDO() {
        return Util.getContextPDO();
    }
}

Then it is simply a matter of injecting a dependency on the interface into MyClass and using the interface, rather than the 3rd party API directly :

public class MyClass {

    private final IPDOFacade ipdoFacade;

    public MyClass(IPDOFacade ipdoFacade) {
        this.ipdoFacade = ipdoFacade;
    }

    private IPDO getIPDO() {
        return ipdoFacade.getContextPDO();
    }

    public String handleIn(Object input) throws Throwable
    {
        String result = "";
        IPDO pdo = getIPDO();

        someImportantBusinessLogic(pdo);

        return result;
    }
    
    ...

}

In your unit test, you can then easily mock your own interface, stub it any way you like and inject it into the unit under test.

This

• avoids the need to make private methods package private.
• makes your tests more readable by avoiding partial mocking.
• applies inversion of control.
• decouples your application from a specific 3rd party library.

I created the following Answer implementation:

public class CapturingAnswer<T, R> implements Answer<T> {

    private final Function<InvocationOnMock, R> capturingFunction;

    private final List<R> capturedValues = new ArrayList<R>();

    public CapturingAnswer(final Function<InvocationOnMock, R> capturingFunction) {
        super();
        this.capturingFunction = capturingFunction;
    }

    @Override
    public T answer(final InvocationOnMock invocation) throws Throwable {
        capturedValues.add(capturingFunction.apply(invocation));
        return null;
    }

    public List<R> getCapturedValues() {
        return Collections.unmodifiableList(capturedValues);
    }

}

This answer captures properties of the invocations being made. The capturedValues can then be used for simple assertions. The implementation uses Java 8 API. If that is not available one would need to use an interface that is able to convert the InvocationOnMock to the captured value. The usage in the testcase is like this:

@Test
public void testSomething() {
    CapturingAnswer<Void,Date> captureDates = new CapturingAnswer<>(this::getEntityDate)
    Mockito.doAnswer(captureDates).when(persistence).save(Mockito.any(Entity.class));

    service.foo();

    Assert.assertNull(captureDates.getCapturedValues().get(0));
}

private Date getEntityDate(InvocationOnMock invocation) {
    Entity entity = (Entity)invocation.getArguments()[0];
    return entity.getDate();
}

The capturing that is done by the presented Answer implementation can't be achieved with Mockitos ArgumentCaptor because this is only used after the invocation of the method under test.

Ok, first things first: I never used Mockito once in a life. But I was curious, so I spent several hours to figure this out and I guess there is much to improve.

So to get this working, we need:

1. The aforementioned (by @jewelsea) JUnit Threading Rule.
2. A custom MockMaker implementation, wrapping the default CglibMockMaker.
3. Wire the things together.

So 1+2 is this:

public class JavaFXMockMaker implements MockMaker {

    private final MockMaker wrapped = new CglibMockMaker();
    private boolean jfxIsSetup;

    private void doOnJavaFXThread(Runnable pRun) throws RuntimeException {
        if (!jfxIsSetup) {
            setupJavaFX();
            jfxIsSetup = true;
        }
        final CountDownLatch countDownLatch = new CountDownLatch(1);
        Platform.runLater(() -> {
            pRun.run();
            countDownLatch.countDown();
        });

        try {
            countDownLatch.await();
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }

    protected void setupJavaFX() throws RuntimeException {
        final CountDownLatch latch = new CountDownLatch(1);
        SwingUtilities.invokeLater(() -> {
            new JFXPanel(); // initializes JavaFX environment
            latch.countDown();
        });

        try {
            latch.await();
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }

    @Override
    public <T> T createMock(MockCreationSettings<T> settings, MockHandler handler) {
        AtomicReference<T> result = new AtomicReference<>();
        Runnable run = () -> result.set(wrapped.createMock(settings, handler));
        doOnJavaFXThread(run);
        return result.get();
    }

    @Override
    public MockHandler getHandler(Object mock) {
        AtomicReference<MockHandler> result = new AtomicReference<>();
        Runnable run = () -> result.set(wrapped.getHandler(mock));
        doOnJavaFXThread(run);
        return result.get();
    }

    @Override
    public void resetMock(Object mock, MockHandler newHandler, @SuppressWarnings("rawtypes") MockCreationSettings settings) {
        Runnable run = () -> wrapped.resetMock(mock, newHandler, settings); 
        doOnJavaFXThread(run);
    }

}

Number 3 is just following the manual:

1. Copy the fully qualified class name of our MockMaker, eg. org.awesome.mockito.JavaFXMockMaker.
2. Create a file "mockito-extensions/org.mockito.plugins.MockMaker". The content of this file is exactly a one line with the qualified name.

Happy testing & kudos to Andy Till for his threading rule.

Warning: This implementation kind of hard-codes the MockMaker to use the CglibMockMaker which might not be be what you want in every case (see the JavaDocs).

I wonder why you want to test, what method your method under tests invoke. Sounds pretty much like whitebox testing to me.

In my opinion, you want to verify the outcome of the invocation and not the way to get there, as this might easily change (i.e. when refactoring).

So if the outcome of doSecond() is the same as doFirst() you could write a test for doFirst() and use the same test (i.e. set of assertions) for testing doSecond().

But if you really want to test, whether doFirst() has been invoked by doSecond() you could wrap your service in a spy and then call the verification on the spy:

//given
SomeService service = new SomeService();
SomeService spy = Mockito.spy(service);
//when
spy.doSecond();
//then
verify(spy).doFirst();

Adding an answer for newer versions of Mockito and Java 8

when(
   mock.method(argThat(t -> t.containsAll(Arrays.asList(IN_PROGRESS, ABANDONED, EXPIRED))))
).thenReturn(myValue);

You are using mockito anyString() while calling the test method, it should be used only for verifying a mock object to ensure a certain method is called with any string parameter inside the test, but not to invoke the test itself. For your test use empty string "" instead to anyString().

proguard-maven-plugin will obfuscate the primary artifact of your project, not the secondary artifact jar-with-dependencies that the maven-assembly-plugin generated.

You need to configure the plugin to obfuscate the jar-with-dependencies by specifying the injar attribute:

Specifies the input jar name (or wars, ears, zips) of the application to be processed.

<injar>${project.build.finalName}-jar-with-dependencies.jar</injar>

Now, there is also a problem in the order of execution of plugins in your POM: we need to make sure that the maven-assembly-plugin is executed before the proguard-maven-plugin. As such, it is best to define an explicit execution for the maven-assembly-plugin bound to the package phase instead of manually invoking it from the command line with assembly:single. This would be the configuration:

<plugin>
    <artifactId>maven-assembly-plugin</artifactId>
    <executions>
        <execution>
            <id>assembly</id>
            <goals>
                <goal>single</goal>
            </goals>
            <phase>package</phase>
            <configuration>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
            </configuration>
        </execution>
    </executions>
</plugin>

and then, you just need to make sure that the proguard-maven-plugin plugin configuration is after that in your POM.

Having done that, invoking Maven with mvn clean install will result in an obfuscated jar with dependencies.

To test with your actual POM, I added two repositories:

• https://repo.spongepowered.org/maven to resolve the spongeapi dependency.
• http://maven.restlet.com to resolve the org.restlet.jse dependencies.

With those 2 dependencies, warnings were generated by ProGuard because the org.restlet.ext.jackson dependency utilizes com.sun.msv.* classes that are not on the buildpath. Since I figure that your code is currently working, it means those classes don't need to be included and that those warnings can be ignored. As such, I added the -dontwarn option so that ProGuard doesn't error when there is a warning.

The final POM for which I was able to successfully obfuscate the jar with dependencies is the following:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mycompany</groupId>
    <artifactId>myproduct</artifactId>
    <version>1.0-SNAPSHOT</version>
    <repositories>
       <repository>
           <id>spongepowered</id>
           <url>https://repo.spongepowered.org/maven</url>
       </repository>
       <repository>
           <id>restlet</id>
           <url>http://maven.restlet.com</url>
       </repository>
    </repositories>
    <properties>
        <restlet-version>2.3.5</restlet-version>
    </properties>
    <build>
       <resources>
            <resource>
                <directory>${project.basedir}/src/main/resources</directory>
                <filtering>true</filtering>
            </resource>
        </resources>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.3</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>templating-maven-plugin</artifactId>
                <version>1.0-alpha-3</version>
                <executions>
                    <execution>
                        <id>filter-src</id>
                        <goals>
                            <goal>filter-sources</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <executions>
                    <execution>
                        <id>assembly</id>
                        <goals>
                            <goal>single</goal>
                        </goals>
                        <phase>package</phase>
                        <configuration>
                            <descriptorRefs>
                                <descriptorRef>jar-with-dependencies</descriptorRef>
                            </descriptorRefs>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>com.github.wvengen</groupId>
                <artifactId>proguard-maven-plugin</artifactId>
                <version>2.0.8</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals><goal>proguard</goal></goals>
                        <configuration>
                            <injar>${project.build.finalName}-jar-with-dependencies.jar</injar> <!-- make sure to obfuscate the jar with dependencies -->
                            <proguardVersion>5.2</proguardVersion>
                            <options>
                                <option>-allowaccessmodification</option>
                                <option>-dontoptimize</option>
                                <option>-dontshrink</option>
                                <option>-dontnote</option>
                                <option>-dontwarn</option> <!-- added option to ignore com.sun missing classes -->
                                <option>-keepattributes Signature</option>
                                <option>-keep class com.mycompany.MyPlugin { *; }</option>
                            </options>
                            <libs>
                                <lib>${java.home}/lib/rt.jar</lib>
                            </libs>
                            <dependencies>
                                <dependency>
                                    <groupId>net.sf.proguard</groupId>
                                    <artifactId>proguard-base</artifactId>
                                    <version>5.2</version>
                                    <scope>runtime</scope>
                                </dependency>
                            </dependencies>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
    <dependencies>
       <dependency>
            <groupId>org.spongepowered</groupId>
            <artifactId>spongeapi</artifactId>
            <version>3.0.0</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
        </dependency>
        <dependency>
            <groupId>org.easytesting</groupId>
            <artifactId>fest-assert-core</artifactId>
            <version>2.0M8</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-core</artifactId>
            <version>1.10.19</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.restlet.jse</groupId>
            <artifactId>org.restlet</artifactId>
            <version>${restlet-version}</version>
        </dependency>
        <dependency>
            <groupId>org.restlet.jse</groupId>
            <artifactId>org.restlet.ext.jackson</artifactId>
            <version>${restlet-version}</version>
        </dependency>
        <dependency>
            <groupId>com.googlecode.json-simple</groupId>
            <artifactId>json-simple</artifactId>
            <version>1.1.1</version>
        </dependency>
    </dependencies>
</project>

The Mock is used to each class or service you are using. The class under test should not be Mocked. Lets assume you are connecting to a remote service which is being built by one of your engineering team, and you are not familiar with its internal functionality but you know what requests and response it returns. In that case, you can create a Mock of that Object, and defines it with set of responses returns in different situations. Each situation should get its own different test and for each response you should check separately the reaction of the code (you are working on).

Another great example is creating a limitation checks. Lets think of exception that might be thrown in some situations. You can Mock the object that will throw the Exception which is simple(~2-3 line of test code if you are using Mock) and you can check how the code you have written reacts to that Exception. Without the Mock the throwing of an exception might be really complicated thing and not so easy to use if you are not familiar with the small details. And of course the Mock enables you to be on focus of the main functionality you are checking cause it make the checking time very very small. And that is a bless when time to market is a critical thing.