How to use AsyncTesting method of org.mockitoutil.async.AsyncTestingTest class

this one did the trick

@Test
void willReturnTheInjectedUUIDValueTest() {

    UUID uuid = UUID.randomUUID();
    Gateway gateway = Mockito.mock(Gateway.class);

    doAnswer(ans -> {
        Consumer<UUID> callback = (Consumer<UUID>) ans.getArgument(1);
        callback.accept(uuid);
        return null;
    }).when(gateway).process(Mockito.any(String.class), Mockito.any(Consumer.class));

    Interactor.builder().gateway(gateway).build().process("ignored", s -> {
        Assertions.assertEquals(uuid.toString(), s);
    });
}

This answer was the hint -> https://stackoverflow.com/a/47226374/148397

The following suggestion let's you test abstract classes without creating a "real" subclass - the Mock is the subclass.

use Mockito.mock(My.class, Mockito.CALLS_REAL_METHODS), then mock any abstract methods that are invoked.

Example:

public abstract class My {
  public Result methodUnderTest() { ... }
  protected abstract void methodIDontCareAbout();
}

public class MyTest {
    @Test
    public void shouldFailOnNullIdentifiers() {
        My my = Mockito.mock(My.class, Mockito.CALLS_REAL_METHODS);
        Assert.assertSomething(my.methodUnderTest());
    }
}

Note: The beauty of this solution is that you do not have to implement the abstract methods, as long as they are never invoked.

In my honest opinion, this is neater than using a spy, since a spy requires an instance, which means you have to create an instantiatable subclass of your abstract 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();

One way is to use a Captor

ArgumentCaptor<List> captor = ArgumentCaptor.forClass(List.class);
verify(mock).createButtons(captor.capture());
assertEquals(x, captor.getValue().size()); // if expecting single list
assertEquals(x, captor.getValues().size()); // if expecting multiple lists

See #15 for the documentation.

You could also use a custom argument matcher. The documentation shows an example that does exactly what you want:

 class IsListOfTwoElements extends ArgumentMatcher<List> {
     public boolean matches(Object list) {
         return ((List) list).size() == 2;
     }
 }
 
 List mock = mock(List.class);
 when(mock.addAll(argThat(new IsListOfTwoElements()))).thenReturn(true);
 mock.addAll(Arrays.asList("one", "two"));
 verify(mock).addAll(argThat(new IsListOfTwoElements()));

You could, for instance, also add a constructor so you can specify list size desired, etc.

Since you are loading configuration class MyApplication.class datasource bean will be created, Try moving datasource in another bean which is not used in a test, make sure all classes loaded for tests are not dependant on datasource.
Or
In your tests create a config class marked with @TestConfiguration and include it in SpringBootTest(classes=TestConfig.class) mocking data source there like

@Bean
public DataSource dataSource() {
    return Mockito.mock(DataSource.class);
}

But this may fail since method call to this mocked datasouce for connection will return null, In that case, you'll have to create an in-memory datasource and then mock jdbcTemplate and rest of dependencies.

The exception is being thrown because you are using a Junit Jupiter @Test annotation but the Junit 4 @Runwith annotation. You should either use org.junit.Test from Junit 4 or annotate the class with @ExtendWith(SpringExtension.class) to use Junit Jupiter.

@WebMvcTest is probably what you want (it implies @AutoConfigureMockMvc, amongst other things).

Relevant docs

The response by david-wallace explains why you run into an OOM: a mock object is remembering details of every invocation.

But an equally important question is: now what to do about it? In addition to what David already suggested, the latest Mockito versions 1.10.19 as well as upcoming 2.0.x now support so-called stubOnly mocks (see javadoc):

stubOnly: A stub-only mock does not record method invocations, thus saving memory but disallowing verification of invocations.

Scala usage example:

import org.mockito.Mockito
val list = Mockito.mock(classOf[Foo], Mockito.withSettings().stubOnly())

// The syntax is a bit more concise when using ScalaTest's MockitoSugar
val foo = mock[Foo](Mockito.withSettings().stubOnly())

Java usage example (untested):

import org.mockito.Mockito;
Foo mock = Mockito.mock(Foo.class, Mockito.withSettings().stubOnly());

The error message outlines the solution. The line

doNothing().when(cmd).dnsCheck(HOST, any(InetAddressFactory.class))

uses one raw value and one matcher, when it's required to use either all raw values or all matchers. A correct version might read

doNothing().when(cmd).dnsCheck(eq(HOST), any(InetAddressFactory.class))

Inner static class configuration: When testing Spring components we usually use @RunWith(SpringJUnit4ClassRunner.class) and make our class @ContextConfiguration. By making class @ContextConfiguration you can create an inner static class for configuration and in it you have full control. There you define all you need as beans and @Autowired it in your test, along with dependencies which can be mocks or regular objects, depending on test case.

Component scanning production code: If there are more components needed for test you can add @ComponentScan but we try to make it scan only packages it needs (this is when you use @Component annotation but in your case you can add XML to @ContextConfiguration). This is a good choice when you do not need mocks and you have a complicated setup which needs to be production like. This is good for integration tests where you want to test how components interact with each other in functional slices you want to test.

Hybrid approach: This is the usual case when you have many beans which need to be production like but one or two need to be mocks. Then you can @ComponentScan production code but add an inner static class which is @Configuration and there define beans with annotation @Primary which will override production code configuration for that bean in case of tests. This is good since you do not need to write long @Configuration with all defined beans, you scan what you need and override what should be mocked.

In your case I would go with first approach like this:

package org.world.hello;

import static org.junit.Assert.*;
import org.mockito.Mockito;
import org.junit.Test;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class RoomTest {

    @Configuration
    //@ImportResource(value = {"path/to/resource.xml"}) if you need to load additional xml configuration
    static class TestConfig {
       @Bean
       public BottleCounter bottleCounter() {
        return Mockito.mock(BottleCounter.class);
       }

       @Bean
       public Room room(BottleCounter bottleCounter) {
         Room room = new Room();
         room.setBottleCounter(bottleCounter);
         //r.setNumBottles(3); if you need 3 in each test
         return room;           
       }
    }

    @Autowired
    private Room room;  //room defined in configuration with mocked bottlecounter

    @Test
    public void testThreeBottlesAreSeperatedByNewLines()
    {
        Mockito.when(b.countBottle(Mockito.anyInt())).thenReturn("a");
        r.setNumBottles(3);
        assertEquals("a\na\na\na\n", r.generatePoem());
    }

}