How to use should_print_actual_and_wanted_in_line method of org.mockitousage.verification.BasicVerificationInOrderTest class

In 2016 you can use runner delegate with PowerMockito, effectively using two runners:

@RunWith(PowerMockRunner.class)
@PowerMockRunnerDelegate(SpringJUnit4ClassRunner.class)

More details here: https://github.com/jayway/powermock/wiki/JUnit_Delegating_Runner

You need to move @EnableJpaAuditing annotation to a separate @Configuration class otherwise it will be loaded even for unrelated application slices.

@Configuration
@EnableJpaAuditing
public class JpaAuditingConfiguration {}

@SpringBootApplication class is used as default configuration for all tests with slices so any additional configuration glued to it will affect more tests than you would expect.

This is also well explained in documentation: User Configuration and Slicing

Try Adding @Spy to your InjectMocks and use the object to "expect" them in a slightly different syntax.

import org.mockito.Spy;

 @InjectMocks
 @Spy
 private MyService myService; 

And now mock the service call

 Mockito.doReturn(mockedSomeObject).when(myService).methodB();

Also change the other mock call to this

Mockito.doReturn(stuff).when(serviceA).method();
Mockito.doReturn(otherStuff).when(serviceB).method();

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).

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.

Building on @Alban's sleuthing in the comments, it looks like adding this annotation to your test case should circumvent the problem:

@PowerMockIgnore("com.smin.dummy.TestAnnotation")

Since the method getApplicationContext is inside the class that you're extending it becomes somewhat problematic. There are a couple of problems to consider:

• You really can't mock a class that is under test, which is one of the many drawbacks with object inheritance (i.e. subclassing).
• The other problem is that ApplicationContext is a singleton, which makes it all more evil to test since you can't easily mock out a global state that is programmed to be irreplaceable.

What you can do in this situation is to prefer object composition over inheritance. So in order to make your Activity testable you need to split up the logic a little. Lets say that your Activity is called MyActivity. It needs to be composed of a logic component (or class), lets name it MyActivityLogic. Here is a simple class-diagram figure:

To solve the singleton problem, we let the logic be "injected" with an application context, so it can be tested with a mock. We then only need to test that the MyActivity object has put the correct application context into MyActivityLogic. How we basically solve both problems is through another layer of abstraction (paraphrased from Butler Lampson). The new layer we add in this case is the activity logic moved outside of the activity object.

For the sake of your example the classes need to look sort-of like this:

public final class MyActivityLogic {

    private MyApp mMyApp;

    public MyActivityLogic(MyApp pMyApp) {
        mMyApp = pMyApp;
    }

    public MyApp getMyApp() {
        return mMyApp;
    }

    public void onClick(View pView) {
        getMyApp().setNewState();
    }
}

public final class MyActivity extends Activity {

    // The activity logic is in mLogic
    private final MyActivityLogic mLogic;

    // Logic is created in constructor
    public MyActivity() {
        super(); 
        mLogic = new MyActivityLogic(
            (MyApp) getApplicationContext());
    }

    // Getter, you could make a setter as well, but I leave
    // that as an exercise for you
    public MyActivityLogic getMyActivityLogic() {
        return mLogic;
    }

    // The method to be tested
    public void onClick(View pView) {
        mLogic.onClick(pView);
    }

    // Surely you have other code here...

}

It should all look something like this:

To test MyActivityLogic you will only need a simple jUnit TestCase instead of the ActivityUnitTestCase (since it isn't an Activity), and you can mock your application context using your mocking framework of choice (since handrolling your own mocks is a bit of a drag). Example uses Mockito:

MyActivityLogic mLogic; // The CUT, Component Under Test
MyApplication mMyApplication; // Will be mocked

protected void setUp() {
    // Create the mock using mockito.
      mMyApplication = mock(MyApplication.class);
    // "Inject" the mock into the CUT
      mLogic = new MyActivityLogic(mMyApplication);
}

public void testOnClickShouldSetNewStateOnAppContext() {
    // Test composed of the three A's        
    // ARRANGE: Most stuff is already done in setUp

    // ACT: Do the test by calling the logic
    mLogic.onClick(null);

    // ASSERT: Make sure the application.setNewState is called
    verify(mMyApplication).setNewState();
}

To test the MyActivity you use ActivityUnitTestCase as usual, we only need to make sure that it creates a MyActivityLogic with the correct ApplicationContext. Sketchy test code example that does all this:

// ARRANGE:
MyActivity vMyActivity = getActivity();
MyApp expectedAppContext = vMyActivity.getApplicationContext();

// ACT: 
// No need to "act" much since MyActivityLogic object is created in the 
// constructor of the activity
MyActivityLogic vLogic = vMyActivity.getMyActivityLogic();

// ASSERT: Make sure the same ApplicationContext singleton is inside
// the MyActivityLogic object
MyApp actualAppContext = vLogic.getMyApp();
assertSame(expectedAppContext, actualAppContext);

Hope it all makes sense to you and helps you out.

I've come across a similar problem when mocking builders, so I thought I'd experiment to see if there is a nicer way.

As Mr Spoon said, it's probably nicer if you can avoid doing do this in the first place as it is not your code and could be assumed to "just work", but I thought I'd give it a go anyway.

I've come up with a (maybe crude) way of doing it by using "default answers" in Mockito. I'm still deciding if I like it or not.

Here's my builder...

public class MyBuilder {

    private StringBuilder my;

    public MyBuilder() {
        my = new StringBuilder();
    }

    public MyBuilder name(String name) {
        my.append("[name=").append(name).append("]");
        return this;
    }

    public MyBuilder age(String age) {
        my.append("[age=").append(age).append("]");
        return this;
    }

    public String create() {
        return my.toString();
    }
}

(Pretty basic right?)

I got my test to look something like this...

// Create a "BuilderMocker" (any better name suggestions welcome!) 
BuilderMocker<MyBuilder> mocker = BuilderMocker.forClass(MyBuilder.class);
// Get the actual mock builder
MyBuilder builder = mocker.build();

// expect this chain of method calls...
mocker.expect().name("[NAME]").age("[AGE]");

// expect this end-of-chain method call...
Mockito.when(builder.create()).thenReturn("[ARGH!]");

Now if I do the following...

System.out.println(builder.name("[NAME]").age("[AGE]").create());

...I expect "[ARGH!]" to be output.

If I altered the last line...

System.out.println(builder.name("[NOT THIS NAME]").age("[AGE]").create());

...then I expect it to break with a NullPointerException.

Here is the actual "BuilderMocker"...

import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
import static org.mockito.Mockito.withSettings;

import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;

public class BuilderMocker<T> {

    private Class<T> clazz;
    private T recorder;
    private T mock;

    // Create a BuilderMocker for the class
    public static <T> BuilderMocker<T> forClass(Class<T> clazz) {
        return new BuilderMocker<T>(clazz);
    }

    private BuilderMocker(Class<T> clazz) {
        this.clazz = clazz;
        this.mock = mock(clazz);
        createRecorder();
    }

    // Sets up the "recorder"
    private void createRecorder() {
        recorder = mock(clazz, withSettings().defaultAnswer(new Answer<Object>() {

            @Override
            public Object answer(InvocationOnMock invocation) throws Throwable {
                // If it is a chained method...
                if (invocation.getMethod().getReturnType().equals(clazz)) {
                    // Set expectation on the "real" mock...
                    when(invocation.getMethod().invoke(mock, invocation.getArguments())).thenReturn(mock);
                    return recorder;
                }
                return null;
            }

        }));
    }

    // Use this to "record" the expected method chain
    public T expect() {
        return recorder;
    }

    // Use this to get the "real" mock...
    public T build() {
        return mock;
    }
}

Not sure if there is a "built-in" way of doing this in Mockito, but this seems to work.

You need to define the behavior for getPath() for folder as it gets called internally in File class.

You can do it as:

File folder = Mockito.mock(File.class);
when(folder.getPath()).thenReturn("C:\temp\");
File file = new Agent().createNewFile(folder, "fileName");

It will work only till you don't really create a new file but only calling new File.