mockito question, I guess its not possible to verify this->method

You can verify are methods on mocked objects called. But in this case I have a method on the class which I am testing which depending on the logic calls one of two other methods.

So I have this->execute, which is the method I am testing, it can call this->executePricing or this->exceuteSearch, but I guess with mockito its not possible to test that the logic is behaving correcly with a verify the correct method was called.

If executePricing and executeSearch do something then presumably you can identify that?
It's all part of what 'execute' does, in that class.

It's not quite clear what you're asking here. perhaps an example might be a good idea.

I assume that "->" is your pseudo-code notation? If you're asking about Java then keeping with the syntax of the language goes a long way to convey meaning. This is where a runnable example comes in handy.

Thanks Dave Tolls rather than verifying that excecute calls executePricing or executeSearch, I should just allow the code to follow through those methods. I do have test cases that handle both those methods.

I thought that would be the case mocking calls only work on mocked methods

I made the assumption (though I'm sure Tony will correct me if I'm wrong) that the two methods, executePrice and executeSearch, are both in the class under test, and can be called when testing the 'execute' method.
And they were wondering how to verify that the relevant one has been called since, obviously, you can't mock them out.

Tony Evans wrote:Thanks Dave Tolls rather than verifying that excecute calls executePricing or executeSearch, I should just allow the code to follow through those methods. I do have test cases that handle both those methods.

I thought that would be the case mocking calls only work on mocked methods

Yep.
It's part of what 'execute' does internally to the class, without interacting with some other interface, so it's part of the unit test for 'execute'.

If it feels like a pain writing tests that incorporate them then it is possible your class is doing too much and maybe those two things should be part of a PricingService and SearchService respectively, but that's a design call on your part really. I (clearly) haven't a clue what it all looks like or how it all fits together...

Tim Cooke I have a object call it service, which I am testing, the objects that service calls are all mocked. But Service the class I am testing is not.

It has three methods excecute, executePricing. executeSearch.

depending on logic flow in exceute it calls excecutePricing or excecuteSearch.

Now if excecutePricing and excecuteSearch were not local methods but methods on a class I was injecting. I could verify they were called with a simple verify(mockAService).excecutePricing(mockMessage);

But as Dave Tolls pointed out these are local methods to the class I am testing so need to drill down into them.

I think I get it. Here's a scenario that I come across from time to time.

You want to test that doTheFirstThing() and doTheSecondThing() are called? Is the order in which they are called important?

Please confirm this is what you're after before I go on.

I'll go on anyway, because it's an interesting technique.

Starting with the production code


Mockito, and the like, don't provide you the ability to do verifications on local instance methods but we can do it ourselves by creating a testable version of the class you want to test. We do this by creating a subclass that overrides the collaborator methods and provides access to inspect whether those methods have been called. We'll need to change the scope of the private collaborator methods from private to protected but that's a minor sacrifice compared to the gains of having your code in a test harness.

Here's the prod code again with the modified accessors.

Now here's the test case with a testable version of the prod code as an inner class that we use to make assertions on whether those local methods get called. The test will fail if either of the methods are not called.

From here it's not difficult to change it to make assertions on the order and frequency in which the collaborating methods are called.

Does that help you with your problem?