Feature request: Method to reset mock interactions without resetting stubs

[GoogleCodeExporter]

In some cases it would be practical to be able to reset the registered 
interactions on a mock while not resetting the stubs
i.e: resetInteractions(mock)

One scenario that comes into mind is testing projects that use dependency 
injection such as Guice, where for testing you set up a TestModule (the 
config-class for the injection) where some of the injected auxiliary classes, 
such as DataAccessObject, MailService, etc are mocked while testing the other 
classes that are injected. As the creation of the mocks then happen outside of 
the JUnit test case and are persisted across test methods it becomes hard to 
verify that a method on the injected mock has happend n times as interactions 
persists across test methods. A reset(mock) would fix that, but the stubs of 
the injected mock would then be reset as well, making further testing of code 
impossible. Especially when testing methods on injected non-mocks that rely on 
state kept in the injected non-mock this will be very difficult, ie. 
authenticationManager.login(xx,xx), then 
authenticationManager.changePassword(xxx).

While it is possible to work around this, for instance recreating the injector 
for every test method (in @Before/setUp()), it would be very practical to be 
able to just reset the interactions. I'm not familiar with mockito internals, 
but I would thing implementing a way of resetting just the interactions, not 
the stubs, should be relatively easy to do 

Original issue reported on code.google.com by dr.torpe...@gmail.com on 11 Feb 2012 at 10:19

[GoogleCodeExporter]

I think we should consider using an existing API for that, e.g. the 
ignoreStubs(...). So that one can do:

reset(ignoreStubs(mockOne, mockTwo));

Having said that I'm thinking that it should just work... although we don't 
have any test for that as the use case for adding ignoreStubs() was completely 
different :)

Original comment by szcze...@gmail.com on 11 Feb 2012 at 3:03

[GoogleCodeExporter]

Ah... no it won't work out of the box.

Original comment by szcze...@gmail.com on 11 Feb 2012 at 3:06

[GoogleCodeExporter]

Original comment by brice.du...@gmail.com on 24 Feb 2012 at 3:53

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

[GoogleCodeExporter]

Original comment by brice.du...@gmail.com on 3 Sep 2012 at 10:00

• Added labels: Injection

[GoogleCodeExporter]

Original comment by brice.du...@gmail.com on 3 Sep 2012 at 10:11

• Removed labels: Injection

[GoogleCodeExporter]

This would probably be the feature that I miss most often in Mockito.

Example use cases is stateful scenarios when you want to call the same method 
multiple times, and evaluate the interactions of each invokation, or when you 
want to test the same method with minor variations to the input, and the 
stubbing and/or input data is non-trivial enough to make you want to avoid 
separate test methods while a common setup method would decrease readability. 
(Yes, the latter is just a matter of personal preference).

Original comment by mattias....@gmail.com on 25 Jun 2013 at 7:18