How to use shouldPrintUnusedStub method of org.mockito.internal.debugging.WarningsFinderTest class

when(
  fooDao.getBar(
    any(Bazoo.class)
  )
).thenReturn(myFoo);

or (to avoid nulls):

when(
  fooDao.getBar(
    (Bazoo)notNull()
  )
).thenReturn(myFoo);

Don't forget to import matchers (many others are available):

For Mockito 2.1.0 and newer:

import static org.mockito.ArgumentMatchers.*;

For older versions:

import static org.mockito.Matchers.*;

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>

Technically speaking both "mocks" and "spies" are a special kind of "test doubles".

Mockito is unfortunately making the distinction weird.

A mock in mockito is a normal mock in other mocking frameworks (allows you to stub invocations; that is, return specific values out of method calls).

A spy in mockito is a partial mock in other mocking frameworks (part of the object will be mocked and part will use real method invocations).

Always remember that the idea behind unit tests (using mocks) is to poke and prode all the dark corners of a single class. They are about making sure that the class behaves as expected for all the sorts of input you can think of. Thats why we use mocks for doing this, because we can program those mocks to do all sorts of things that might be difficult to reproduce if the class was hooked up to the rest of the application.

Integration on the other hand, has a different emphasis. It's about making sure that all your classes work together to produce the desired result. So keep that in mind when coding them. It's the big picture that you are after. You don't need to worry about obsure edge cases of individual classes because that's the job of your mocked unit tests. But things like database state are exactly why integration tests are important.

I also agree with @stivlo about using products like HSQL for in memory database work. They can both speed up integration testing and help to ensure a known starting point for a test.

I would suggest keeping your unit tests and integration tests in seperate directories or at least seperate packages named to match. Simple because it helps you to remember what you are dealing with.

Also watch out for test creep. Ie. Unit tests that are instantiating a lot of application classes and really should be moved into integration tests, and integration tests that are doing lots of detailed variation style tests on a class - candidates for a unit test. Particularly with the last you can prune a lot of time off a build if there are integration tests which should not exist.

Finally like any code, test code needs a little love and attention from time to time. So keep an eye out for refactoring opportunities. That being said, I've also seen test code that has become difficult to work with because it's too generalised and over engineered. Remember test code is not production code, so in most cases clarity is far more important than engineering. It's a balance that you will get through experience.

Weird that your solution seems to work.
According to their documentation on Github it says.

Mocking of final classes and methods is an incubating, opt-in feature. It uses a combination of Java agent instrumentation and subclassing in order to enable mockability of these types. As this works differently to our current mechanism and this one has different limitations and as we want to gather experience and user feedback, this feature had to be explicitly activated to be available ; it can be done via the mockito extension mechanism by creating the file src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker containing a single line:

mock-maker-inline

After you created this file, Mockito will automatically use this new engine and one can do :

 final class FinalClass {
   final String finalMethod() { return "something"; }
 }

 FinalClass concrete = new FinalClass(); 

 FinalClass mock = mock(FinalClass.class);
 given(mock.finalMethod()).willReturn("not anymore");

 assertThat(mock.finalMethod()).isNotEqualTo(concrete.finalMethod());

In subsequent milestones, the team will bring a programmatic way of using this feature. We will identify and provide support for all unmockable scenarios. Stay tuned and please let us know what you think of this feature!

My working structure now looks like this.

First of all, you should always mock the direct dependencies of an object, and not its transitive dependencies. So you should mock B, and not C, to test A. Then you would write a unit test for B by mocking C.

Second: you're not injecting the mock anywhere in the unit test. What you should have is:

public class Test {

    // not autowired here
    private A a;

    private B mockB;

    @Test
    public void testA() {
        mockB = mock(B.class);
        when(b.bFn(), anyInt()).thenReturn(something);

        // the missing part: injecting the mock into the tested object
        a = new A(mockB);
        // or a = new A();
        //    a.setB(mockB);

        assertEquals(0, a.aFn());
    }
}

When you use mock(B.class), you get one mock instance of B. That doesn't mean that all the other instances of B will do what the mock does.

Mocking C to test A is a bad practice: unit tests should test one class in isolation of the others. But if you really want that, then create a mock C, create a B and inject the mock C inside it, then create an A and inject the B inside it.

A --> B --> mockC

You need to put the class where the constructor is called into the @PrepareForTest annotation instead of the class which is being constructed - see Mock construction of new objects.

In your case:

✗ @PrepareForTest(MyQueryClass.class)

✓ @PrepareForTest(A.class)

More general:

✗ @PrepareForTest(NewInstanceClass.class)

✓ @PrepareForTest(ClassThatCreatesTheNewInstance.class)

You need to provide a way of accessing the member variables so you can pass in a mock (the most common ways would be a setter method or a constructor which takes a parameter).

If your code doesn't provide a way of doing this, it's incorrectly factored for TDD (Test Driven Development).

You can create a directory for your testing source code, i.e. src/test/java. You can do this from the command line or using the Project view in the Project tool window. The new directory should be highlighted in green at this point.

Also make sure to choose the correct build variant.

For more details on how to configure all this and run the tests properly, please refer http://tools.android.com/tech-docs/unit-testing-support

Hope this helps.