Create Mockito.reset() [i.e. no args] to reset all mocks

[GoogleCodeExporter]

Assuming I have a dependency injection framework that is injecting mocks
for me, I don't necessarily know what beans are in what state across my
unit test.

Rather than call Mockito.reset(bean1,bean2,...) which could get out of date
and is verbose, I would prefer that Mockito keeps track of what mocks have
been created, and resets them all when Mockito.reset() is called.

Original issue reported on code.google.com by nea...@gmail.com on 8 Sep 2009 at 2:46

[GoogleCodeExporter]

Hi,

Mockito cannot know how many mocks have been created in particular test case. 
Unless
you are using a JUnit runner that can keep track on created mocks. Makes sense 
if
reset() without args reset all mocks only if runner is in place?

Original comment by szcze...@gmail.com on 8 Sep 2009 at 6:19

[GoogleCodeExporter]

Good point.  Seems to me that there's a few things that the runtime context 
could
detect and deal with.

A Mockito aware JUnit runner could, for example reset @Mock annotated items 
between
tests.

[And a Spring-aware one would add @Mock annotated beans to the spring context to
allow those mocks to be wired in].

The Spring use case is what I've come up against... looks like a bit more 
thinking
through is needed at my end.

Original comment by nea...@gmail.com on 9 Sep 2009 at 11:04

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 20 Oct 2009 at 7:30

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

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 11 Nov 2009 at 9:06

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

How about this api for resetting all:

Mockito.reset().allIn(this);

Where 'this' is a test class?

Original comment by szcze...@gmail.com on 14 Nov 2009 at 5:13

[GoogleCodeExporter]

In terms of the api for "resetting all":
1. Mockito.reset(this) - where 'this' is a test class OR a mock/mocks
2. Mockito.resetAll(), Mockito.resetAll(this) would also be an option, in my 
opinion
3. I'd vote against Mockito.reset().allIn(this), as I didn't find it intuitive 
enough.

"... and a Spring-aware one would add @Mock annotated beans to the spring 
context to
allow those mocks to be wired in ..."
- this would be a dream come true (at least, from my Spring-filtered 
perspective). 
I've had to resort to xml-based Spring configuration for mocks so far (rather 
than 
using the clean and beautiful @Mock annotation) to get the Spring DI working 
with 
Mockito... It would be absolutely fantastic to have @Mock integrated with 
Spring DI 
(via a runner).

"A Mockito aware JUnit runner could, for example reset @Mock annotated items 
between
tests." 
- that would be another dream come true (but I would give it up for the 1st 
dream!)

If these 2 features above existed, I think this would greatly help in promoting 
Mockito in the Spring community. The user wouldn't need to worry about 
dependencies, 
mock resetting, xml configuration... Just annotate the required resources, sit 
back 
and enjoy your mockito ;)

Original comment by albel...@gmail.com on 1 Dec 2009 at 8:45

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 14 Feb 2010 at 10:04

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

Assuming you're using Spring, you can easily implement this yourself by 
obtaining
your ApplicationContext and then doing the following:

    public static void resetMocks(ApplicationContext context) {
        for ( String name : context.getBeanDefinitionNames() ) {
            Object bean = context.getBean( name );
            if (new MockUtil().isMock( bean )) {
                Mockito.reset( bean );
            }
        }
    }

Original comment by brian.la...@gmail.com on 20 May 2010 at 6:59

[GoogleCodeExporter]

Thanks, Brian, it's a pretty neat solution.
I started using the new @InjectMocks annotation - I love it because it performs 
mock 
injection without using the Spring container/context. It supports setter 
injection as 
well as annotation-based injection, so it's exactly what I was looking for.

Original comment by albel...@gmail.com on 20 May 2010 at 7:07

[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