How to use shouldCustomMatcherPrintDescriptionBasedOnName method of org.mockitousage.matchers.CustomMatcherDoesYieldCCETest class

It is pretty easy to test an aspect (including its pointcut expressions) in isolation, without the whole web context (or any context at all).

I will first try to give a generalized example, not the one that was in the OP question.

Let's imagine that we have an aspect that must throw an exception if a method's first argument is null, otherwise allow the method invocation proceed.

It should only be applied to controllers annotated with our custom @ThrowOnNullFirstArg annotation.

@Aspect
public class ThrowOnNullFirstArgAspect {
    @Pointcut("" +
            "within(@org.springframework.stereotype.Controller *) || " +
            "within(@(@org.springframework.stereotype.Controller *) *)")
    private void isController() {}

    @Around("isController()")
    public Object executeAroundController(ProceedingJoinPoint point) throws Throwable {
        throwIfNullFirstArgIsPassed(point);
        return point.proceed();
    }

    private void throwIfNullFirstArgIsPassed(ProceedingJoinPoint point) {
        if (!(point.getSignature() instanceof MethodSignature)) {
            return;
        }

        if (point.getArgs().length > 0 && point.getArgs()[0] == null) {
            throw new IllegalStateException("The first argument is not allowed to be null");
        }
    }
}

We could test it like this:

public class ThrowOnNullFirstArgAspectTest {
    private final ThrowOnNullFirstArgAspect aspect = new ThrowOnNullFirstArgAspect();
    private TestController controllerProxy;

    @Before
    public void setUp() {
        AspectJProxyFactory aspectJProxyFactory = new AspectJProxyFactory(new TestController());
        aspectJProxyFactory.addAspect(aspect);

        DefaultAopProxyFactory proxyFactory = new DefaultAopProxyFactory();
        AopProxy aopProxy = proxyFactory.createAopProxy(aspectJProxyFactory);

        controllerProxy = (TestController) aopProxy.getProxy();
    }

    @Test
    public void whenInvokingWithNullFirstArg_thenExceptionShouldBeThrown() {
        try {
            controllerProxy.someMethod(null);
            fail("An exception should be thrown");
        } catch (IllegalStateException e) {
            assertThat(e.getMessage(), is("The first argument is not allowed to be null"));
        }
    }

    @Test
    public void whenInvokingWithNonNullFirstArg_thenNothingShouldBeThrown() {
        String result = controllerProxy.someMethod(Descriptor.builder().externalId("id").build());
        assertThat(result, is("ok"));
    }

    @Controller
    @ThrowOnNullFirstArg
    private static class TestController {
        @SuppressWarnings("unused")
        String someMethod(Descriptor descriptor) {
            return "ok";
        }
    }
}

The key part is inside the setUp() method. Please note that it also allows to verify the correctness of your pointcut expression.

How to test that the aspect method actually gets called?

If the aspect method only has some some effect that is difficult to verify in tests, you could use a mock library like Mockito and make a stub around your real aspect and then verify that the method was actually called.

private ControllerExceptionAspect aspect = Mockito.stub(new     ControllerExceptionAspect());

Then in your test, after invoking the controller via proxy

Mockito.verify(aspect).afterThrowingAdvice(Matchers.any());

How to test that the aspect method actually writes to log?

If you are using logback-classic, you could write an Appender implementation and add it to the Logger of interest, and then inspect whether a message that you expect gets logged or not.

public class TestAppender extends AppenderBase<ILoggingEvent> {
    public List<ILoggingEvent> events = new ArrayList<>();

    @Override
    protected void append(ILoggingEvent event) {
        events.add(event);
    }
}

In the fixture setup:

appender = new TestAppender();
// logback Appender must be started to accept messages
appender.start();
ch.qos.logback.classic.Logger logger = (ch.qos.logback.classic.Logger) LoggerFactory.getLogger(ControllerExceptionAspect.class.class);
logger.addAppender(appender);

and in your test:

List<ILoggingEvent> errors = appender.events.stream()
        .filter(event -> event.getLevel() == Level.ERROR)
        .collect(Collectors.toList());
assertEquals("Exactly one ERROR is expected in log", 1, errors.size());
// any other assertions you need

Probably you would also need to stop() the Appender in @After method, but I'm not sure.

Finally I got some times to investigate and I made it. Here is my solution.

@RunWith(PowerMockRunner.class)
@PowerMockRunnerDelegate(VertxUnitRunner.class)
@PrepareForTest({ MongoClient.class })
public class PersistenceTest {

private MongoClient mongo;
private Vertx vertx;

@Before
public void initSingleTest(TestContext ctx) throws Exception {
  vertx = Vertx.vertx();
  mongo = Mockito.mock(MongoClient.class);
  PowerMockito.mockStatic(MongoClient.class);
  PowerMockito.when(MongoClient.createShared(Mockito.any(), Mockito.any())).thenReturn(mongo);
  vertx.deployVerticle(Persistence.class, new DeploymentOptions(), ctx.asyncAssertSuccess());
}

@SuppressWarnings("unchecked")
@Test
public void loadSomeDocs(TestContext ctx) {
  Doc expected = new Doc();
  expected.setName("report");
  expected.setPreview("loremipsum");
  Message<JsonObject> msg = Mockito.mock(Message.class);
  Mockito.when(msg.body()).thenReturn(JsonObject.mapFrom(expected));
  JsonObject result = new JsonObject().put("name", "report").put("preview", "loremipsum");
  AsyncResult<JsonObject> asyncResult = Mockito.mock(AsyncResult.class);
  Mockito.when(asyncResult.succeeded()).thenReturn(true);
  Mockito.when(asyncResult.result()).thenReturn(result);
  Mockito.doAnswer(new Answer<AsyncResult<JsonObject>>() {
    @Override
    public AsyncResult<JsonObject> answer(InvocationOnMock arg0) throws Throwable {
    ((Handler<AsyncResult<JsonObject>>) arg0.getArgument(3)).handle(asyncResult);
    return null;
    }
  }).when(mongo).findOne(Mockito.any(), Mockito.any(), Mockito.any(), Mockito.any());
  Async async = ctx.async();
  vertx.eventBus().send("persistence", new JsonObject(), msgh -> {
    if (msgh.failed()) {
    System.out.println(msgh.cause().getMessage());
    }
    ctx.assertTrue(msgh.succeeded());
    ctx.assertEquals(expected, Json.decodeValue(msgh.result().body().toString(), Doc.class));
    async.complete();
  });
  async.await();
  }
}

Use Powemockito to mock the MongoClient.createShared static method, so you'll have your mock when verticle starts. Mocking async handler is a bit of code to write. As you can see mocking start at Message<JsonObject> msg = Mockito.mock(Message.class); and ends at Mockito.doAnswer(new Answer.... In the Answer's method pick the handler param and force it to handle your async result then you're done.

@InjectMocks is a Mockito mechanism for injecting declared fields in the test class into matching fields in the class under test. It doesn't require the class under test to be a Spring component.

@Autowired is Spring's annotation for autowiring a bean into a production, non-test class.

If you wanted to leverage the @Autowired annotations in the class under test, another approach would be to use springockito which allows you to declare mock beans so that they will be autowired into the class under test the same way that Spring would autowire the bean. But typically that's not necessary.

As for me the easiest way it's just to save the link to the read object when you initialize your Spy object:

Foo realFoo = new Foo();
Foo spyFoo = Mockito.spy(realFoo);

Now you can stub it like this:

doAnswer(invocation -> realFoo.getSome() + "spyMethod").when(spyFoo).getSome();

One more way is to call invocation.callRealMethod():

doAnswer(invocation -> invocation.callRealMethod() + "spyMethod").when(spyFoo).getSome();

But in this case you may need to cast the return value as long as invocation.callRealMethod() returns Object.

Your test doesn't test any of your code. It tests that Mockito works fine.

When I introduce the concept of mocking, I take this example: suppose you build a detonator, and want to test it. You could of course use the detonator with a real bomb, and see if the whole block explodes when you use the detonator. But that isn't very practical. BTW, maybe you don't even have a bomb at your disposal. Maybe your colleague is still building it.

So you use a mock bomb. Note the important point: to test the detonator, you use a mock bomb. Not a mock detonator. What is mocked is the dependency of the class under test. Not the class under test itself.

What is a mock bomb? It's just a fake bomb that doesn't do anything. All it does is allowing to verify if has been asked to explode or not. So your code to test the detonator would be like this:

// create a mock bomb:
Bomb mockBomb = mock(Bomb.class);
// create a real detonator, but tie it to the mock bomb:
Detonator detonator = new Detonator(mockBomb);

// test the detonator. Since it's tied to a mock bomb, the block
// won't explode
detonator.pressTheRedButton();

// check it the mock bomb has been asked to explode, as it should 
// if the detonator works correctly
verify(mockBomb).explode();

Now if the test passes, you know that all the internal circuitry that is used in pressTheRedButton() works fine and eventually tells the bomb to explode. So you know that, when used with a real bomb, the real bomb will be asked to explode as well when pressing the red button.

Now let's come back to the real world: you want to test a service, and this service uses a DAO that needs a database, populated with data, to run fine. To test your service, you can simply mock the DAO, and verify it works fine. The mock DAO can also be used as a stub, i.e. an object that returns what you tell it to return in the test, instead of actually querying the database. That's what you're doing in the code in your question: you're telling the mock MyClass instance that, when add() is called with 2 and 2 as arguments, it should return 4.

This makes the test easier to setup, faster to run, and independant from the actual code of the DAO, which is not what you want to test in the unit test of the service.

Your could also use real methods, preparing and removing the configuration before and after each test:

@Before
public void setUp() {
    System.setProperty("flag", "true");
}

@After
public void tearDown() {
    System.clearProperty("flag");
}

What you are asking is not possible because your legacy code relies on a static method getInstance() and Mockito does not allow to mock static methods, so the following line won't work

when(FormatterService.getInstance()).thenReturn(formatter);

There are 2 ways around this problem:

1. Use a different mocking tool, such as PowerMock, that allows to mock static methods.

2. Refactor your code, so that you don't rely on the static method. The least invasive way I can think of to achieve this is by adding a constructor to DriverSnapshotHandler that injects a FormatterService dependency. This constructor will be only used in tests and you production code will continue to use the real singleton instance.

   public static class DriverSnapshotHandler {
   
       private final FormatterService formatter;
   
       //used in production code
       public DriverSnapshotHandler() {
           this(FormatterService.getInstance());
       }
   
       //used for tests
       DriverSnapshotHandler(FormatterService formatter) {
           this.formatter = formatter;
       }
   
       public String getImageURL() {
           return formatter.formatTachoIcon();
       }
   }
   

Then, your test should look like this :

FormatterService formatter = mock(FormatterService.class);
when(formatter.formatTachoIcon()).thenReturn("MockedURL");
DriverSnapshotHandler handler = new DriverSnapshotHandler(formatter);
handler.getImageURL();
verify(formatter, atLeastOnce()).formatTachoIcon();

JUnit 5 has @TestInstance(PER_CLASS) annotation that can be used for this purpose. One of the features that it enables is non-static BeforeAll and AfterAll methods:

@TestInstance(PER_CLASS)
class BeforeAllTests {

    lateinit var isInit = false

    @BeforeAll
    fun setup() {
        isInit = true
    }

   @TestFactory
   fun beforeAll() = listOf(
       should("initialize isInit in BeforeAll") {
           assertTrue(isInit)
       }
   )
}

fun should(name: String, test: () -> Unit) = DynamicTest.dynamicTest("should $name", test)

Here is the solution to the above mentioned scenario. As I was not interested in testing the invocation of newTransactionTemplate.execute(), it being an spring API. I wanted to test the invocation of reserveService.callReserve(reserveDetails) and reserveService.callRelease(id). The only way to test this is if we create a transactiontemplate/transactioncallback "real" implementation/stub that is just pass thru. so the doIntransaction method should do nothing more than execute the action. then we can set expectation on the action methods which in this case is the reserveService.

    when(mockTransactionTemplate.execute(Mockito.<TransactionCallback>any())).thenAnswer(new Answer() {
         public Object answer(InvocationOnMock invocation) {
             Object[] args = invocation.getArguments();
           TransactionCallback arg = (TransactionCallback)args[0];
             return arg.doInTransaction(new SimpleTransactionStatus());
         }
     });     
    when(mockResourceService.callReserve(any(ReserveDetails.class))).thenReturn(reserveInfo);
    when(mockResourceService.callRelease(eq(id))).thenReturn(releaseInfo);

    //Call the exe method
    someService.exe();

    verify(mockResourceService, times(1)).callReserve(any(ReserveDetails.class));
    verify(mockSomeOtherService, times(1)).doSomthing());
    verify(mockMemberResourceService, times(1)).callRelease(eq(id));