How to use shouldUseCustomAnnotation method of org.mockitousage.configuration.CustomizedAnnotationForSmartMockTest class

InOrder helps you to do that.

ServiceClassA firstMock = mock(ServiceClassA.class);
ServiceClassB secondMock = mock(ServiceClassB.class);

Mockito.doNothing().when(firstMock).methodOne();   
Mockito.doNothing().when(secondMock).methodTwo();  

//create inOrder object passing any mocks that need to be verified in order
InOrder inOrder = inOrder(firstMock, secondMock);

//following will make sure that firstMock was called before secondMock
inOrder.verify(firstMock).methodOne();
inOrder.verify(secondMock).methodTwo();

The alternative is to use the @Mock annotation since then Mockito can use type reflection to find the generic type:

public class MyTest {

  @Mock
  private ArrayList<String> mockArrayList;

  ...

  public void setUp() {
    MockitoAnnotations.initMocks(this);
  }

  public void testMyTest() {
    when(mockArrayList.get(0)).thenReturn("Hello world");

    String result = mockArrayList.get(0);

    assertEquals("Should have the correct string", "Hello world", result);

    verify(mockArrayList).get(0);
  }
}

You can do that by instantiating your main class with parametrized constructor in your junit and then creating a spy from it.

Let's suppose your main class is A. Where B and C are its dependencies

public class A {

    private B b;

    private C c;

    public A(B b,C c)
    {
        this.b=b;
        this.c=c;
    }

    void method() {
        System.out.println("A's method called");
        b.method();
        c.method();
        System.out.println(method2());

    }

    protected int method2() {
        return 10;
    }
}

Then you can write junit for this using your parametrized class as below

@RunWith(MockitoJUnitRunner.class)
public class ATest {

    A a;

    @Mock
    B b;

    @Mock
    C c;

    @Test
    public void test() {
        a=new A(b, c);
        A spyA=Mockito.spy(a);

        doReturn(20).when(spyA).method2();

        spyA.method();
    }
}

Output of test class

A's method called
20

1. Here B and C are mocked object that you injected in your class A using parametrized constructor.
2. Then we created a spy of A called spyA.
3. We checked if spy is really working by modifying the return value of a protected method method2 in class A which could not have been possible if spyA was not an actual spy of A.

spring.main.allow-bean-definition-overriding=true can be placed in test configurations. If you need extensive integration testing, you will need to override beans at some point. It's inevitable.

Though the correct answer has already been provided, it implies that your bean will have different names. So, technically, it's not an override.

If you need a real override (because you use @Qualifiers, @Resources or something similar), since Spring Boot 2.X is only possible using the spring.main.allow-bean-definition-overriding=true property.

Update: Be careful with Kotlin Bean Definition DSL. In Spring Boot it will require a custom ApplicationContextInitializer, like so:

class BeansInitializer : ApplicationContextInitializer<GenericApplicationContext> {

    override fun initialize(context: GenericApplicationContext) =
            beans.initialize(context)

}

Now if you decide to override one of such DSL-based beans in your test via @Primary @Bean method, it will not do. The initializer will kick in after @Bean methods and you'd still get the initial, DSL-based bean in your tests even with @Primary on the test @Bean. One other option would be to also create a test initializer for your tests and list them all in your test properties, like so(order matters):

context:
    initializer:
        classes: com.yuranos.BeansInitializer, com.yuranos.TestBeansInitializer

Bean Definition DSL also supports primary property via:

bean(isPrimary=true) {...}

- which you'll need to eliminate ambiguity when you try to inject a bean, however main:allow-bean-definition-overriding: true is not needed if you go pure DSL way.

(Spring Boot 2.1.3)

Roughly speaking, a then-block may only contain assertions in the form of boolean expressions. A Mockito verification expression doesn't fit this contract, as it will return a falsy value (null, false, 0) when it passes, which is interpreted as a failed assertion by Spock.

To solve this problem, you can either write a helper method that wraps around the verification expressions and always returns true, or you can use Spock's built-in mocking framework instead of Mockito.

It should work using the @Captor annotation:

@Captor
    private ArgumentCaptor<ArrayList<SomeType>> captor;

For @Async semantics to be adhered, some active @Configuration class will have the @EnableAsync annotation, e.g.

@Configuration
@EnableAsync
@EnableScheduling
public class AsyncConfiguration implements AsyncConfigurer {

  //

}

To resolve my issue, I introduced a new Spring profile non-async.

If the non-async profile is not active, the AsyncConfiguration is used:

@Configuration
@EnableAsync
@EnableScheduling
@Profile("!non-async")
public class AsyncConfiguration implements AsyncConfigurer {

  // this configuration will be active as long as profile "non-async" is not (!) active

}

If the non-async profile is active, the NonAsyncConfiguration is used:

@Configuration
// notice the missing @EnableAsync annotation
@EnableScheduling
@Profile("non-async")
public class NonAsyncConfiguration {

  // this configuration will be active as long as profile "non-async" is active

}

Now in the problematic JUnit test class, I explicitly activate the "non-async" profile in order to mutually exclude the async behavior:

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = Application.class)
@WebAppConfiguration
@IntegrationTest
@Transactional
@ActiveProfiles(profiles = "non-async")
public class SomeServiceIntTest {

    @Inject
    private SomeService someService;

        @Test
        public void testAsyncMethod() {

            Foo testData = prepareTestData();

            someService.asyncMethod(testData);

            verifyResults();
        }

        // verifyResult() with assertions, etc.
}

You can use Mockito's answers, so instead of:

Mockito.when(client.get(Mockito.any(Request.class))).thenReturn("100");

write:

Mockito.when(client.get(Mockito.any(Request.class)))
 .thenAnswer(new Answer() {
   Object answer(InvocationOnMock invocation) {
     Object[] args = invocation.getArguments();
     Object mock = invocation.getMock();
     return "called with arguments: " + args;
   }
});

Mocks that return have the expectation that the return type matches the mocked object's return type.

Here's the mistake:

Mockito.when(remoteStore.get("a", "b")).thenReturn("lol");

"lol" isn't an Optional<String>, so it won't accept that as a valid return value.

The reason it worked when you did

Optional<Object> returnCacheValue = Optional.of((Object) returnCacheValueString);
Mockito.<Optional<Object>>when(remotestore.get("cache-name", "cache-key")).thenReturn(returnCacheValue);

is due to returnCacheValue being an Optional.

This is easy to fix: just change it to an Optional.of("lol") instead.

Mockito.when(remoteStore.get("a", "b")).thenReturn(Optional.of("lol"));

You can also do away with the type witnesses as well. The result above will be inferred to be Optional<String>.