Addind an InvocationListener to a mock, after it has been created. More specific, make a mock verbose.

[GoogleCodeExporter]

Hi,

Can we have such the functionality below "officially" part of Mockito? Maybe in 
MockitoDebuggerImpl? It seems to be only way to attach an InvocationListener to 
a mock *after* it has been created.

I find such a method useful when dealing with legacy code tested with mockito. 
The place where the mock is created is not (easily) reachable to me.

    public static void makeMockVerbose(Object mock) {

        Factory factory = (Factory) mock;
        MethodInterceptorFilter filter = (MethodInterceptorFilter) factory.getCallback(0);
        InternalMockHandler<?> mockHandler = (InternalMockHandler<?>) filter.getHandler();
        MockCreationSettings settings = mockHandler.getMockSettings();
        settings.getInvocationListeners().add(new VerboseMockInvocationLogger());
    }

Original issue reported on code.google.com by ccrav...@gmail.com on 27 Mar 2015 at 9:53

[GoogleCodeExporter]

Hi,

We don't use google code anymore, and as a matter of fact this platform will be 
closed by google in less than a year. Please create an issue at github : 
https://github.com/mockito/mockito

About this change I don't see the added value, i.e, why not make it verbose 
from the start ?

Original comment by brice.du...@gmail.com on 27 Mar 2015 at 2:40

[GoogleCodeExporter]

As I said, I work with legacy code and the creation point of the mocks is not 
easily accessible. The mocks are created in a Spring context, and I cannot 
change it or the classes that create the mocks without having to recompile and 
redeploy and it's simply too much of a pain. It seems a bit unflexible that the 
list of invocation listeners is buried so deep and can hardly be changed after 
creation moment. I would expect a mock to be easily configurable any moment up 
to the point when I start the test and use it.

My use case is, as I try to refactor the tests, I try to find out first what 
actual methods are actually called by the SUT on a mock and also important, 
what the mocked methods return (unfortunately you cannot see that with 
MockitoDebuggerImpl.printInvocations). Having little control on the creation of 
the mock, this is a method that I was able to concoct, and it seems to work. 
The problem with it is that it depends a lot on the internals of Mockito, and 
therefore can be easily broken by future changes, and that's why I was asking 
if maybe it could become officialy part of Mockito.

As you can see, the world is full of unexpected use cases. What is added value 
or not is in the eyes of the beholder.

Original comment by ccrav...@gmail.com on 27 Mar 2015 at 3:14

[GoogleCodeExporter]

Well, legacy...

Please, please create the issue on github ;)
The discussion can continue there.

Original comment by brice.du...@gmail.com on 27 Mar 2015 at 3:51

• Added labels: Type-Enhancement
• Removed labels: Type-Defect