How to test anonymous methods with JUnit or Mockito?

Why it doesn't work

Well your problem here is that TransactionTemplate in your test is a mock. As such it has the same interface as TransactionTemplate but it does not know how to behave. You are in charge of its implementation - that's the whole point of mocks. You are explicitly calling template.execute() in your code and that is why your first verify passes. But that execute() isn't the one from Spring (or more precisely template in your test isn't an instance of Spring's TransactionTemplate, it's only a mock of it) - it's, well lets say it's "empty" as it is invoked on a mock and you did not tell the mock how invoking execute() on it should behave.

How I would fix it

In cases like this I would really discourage you from such unit tests because you are testing implementation here. What you should test, at least according to me, is the functionality meaning given certain conditions, when something happens then some result should occur. This would require changing this to an integration test (using lets say DBUnit or anything else) and asserting if you actually deleted what you were supposed to delete. I mean what do you really care about - knowing that some methods got invoked or that something you hoped for actually happened?

How you can, but IMHO shouldn't, fix it.

But if you really want to test that anonymous piece of code then I would simply extract it (the whole anonymous class) to a separate class and write a unit test just for that new class and more precisely for it's doInTransaction() method. In that case you would create it using new, setting a mock DataWarehouseMessageDao in it and simply do your verify().

You shouldn't change your code, it's right. In your unit test, instead of isA check, you should use ArgumentCaptor to capture passed parameter, validate that instance is type of TransactionCallback and invoke doInTransaction method on it. So you would be able to verify that dao was invoked with expected parameter (advice you could use eq matcher to verify exact value).

It's true that in this test you gonna test two things at a time, but it's only because of your implementation and I'm not saying that it's wrong. Creating new instances with some business logic always increase coupling in your code, but it doesn't mean that we shouldn't use language abilities to do that.