Add support for managed mocks and auto-verification

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Write a test case
2. Using mockito and stub (train) some mocks
3. Forget to verify all the interactions

What is the expected output? What do you see instead?
All managed mocks should be auto verified i.e. extra invocations flagged as a 
fail and missing invocations flagged as a fail.
Instead, the test passes

What version of the product are you using? On what operating system?
Using version mockito-0.5.1 (and on WinXP+SP3 and Win7x64

Please provide any additional information below.

I have knocked-up an implementation of this; I can't imagine supports all 
testing patterns/models/usages, but it satisfies my 'TestCase w/ setUp and 
tearDown' needs.

Will attach later after I've tidied it up.

Original issue reported on code.google.com by dbisho...@gmail.com on 18 Aug 2010 at 5:20

[GoogleCodeExporter]

B.t.w. I couldn't find the 'New enhancement' button :-p

Original comment by dbisho...@gmail.com on 18 Aug 2010 at 5:21

[GoogleCodeExporter]

As promised...

I tried to say in my initial comments that I use nose, so you'll need that for 
the @raises decorator.

I hope the provided test case is sufficient to describe the feature.

Would be great if this gets folded into the code-base at some point.

Cheers, Darren

Original comment by dbisho...@gmail.com on 18 Aug 2010 at 10:24

Attachments:

• mockito_test_helper.py
• auto_verification_test.py

[GoogleCodeExporter]

Hey! this is a great feature, thanks for contribution. But, what I think should 
be done a bit different is the API. 
In my opinion it should be integrated into `mock` function. Say:
{{{
auto_mock = mock(Clazz, autoVerify=True)
}}}
You can probably think of better naming of parameter ;)

What do you think about that?
I will have some time for mockito this weekend so I can incorporate the patch 
hopefuly.

Thanks again for contribution!

Original comment by serhiy%oplakanets.com@gtempaccount.com on 1 Sep 2010 at 9:15

[GoogleCodeExporter]

Also, I missed the point that you're tightly connected to PyUnit. 
I, for example, use nose tests at my daily work and I believe some people do it 
also. Can we think of smarter way to integrate with unit test tools?

Original comment by serhiy%oplakanets.com@gtempaccount.com on 1 Sep 2010 at 9:16

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by serhiy%oplakanets.com@gtempaccount.com on 1 Sep 2010 at 9:17

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

[GoogleCodeExporter]

Hey glad to read that you're interested in this feature.

I never said I was tightly connected to PyUnit but I did say I use 'nose'. As 
far as I can tell, I have not (intentionally) implemented any dependencies on 
PyUnit or Nose. 'setUp' is the only important part; as long as the 'setUp' 
method that is decorated is invoked as and when we'd expected by what ever 
test-runner is being used, then it should all work.

Truth is my background is in Java and Flex, so I really don't know the best 
Python way to do this kind of thing; I think this problem is solved either in 
the Java version or the Flex version... or both, can't quite recall.

Anyway, I don't recognise/understand the syntax you have used? The only place I 
see braces are in dict-literals.
...or is that the code-formatting syntax for this issue tracker???

As I understand the code, mock(...) is actually a class and Mock(...) (also a 
class) exists but is deprecated(?). It's your baby, but I'd prefer to bring 
Mock(...) back and have mock(...) and auto_mock(...) as factory methods. I have 
taken this approach with nice(...) and strict(...) and declared suitable 
default values which facilitates them being used as 'construction-strategy' 
objects, which in turn support the @with_mockito decorator. Sounds over 
engineered but the code turns out to be very simple.

BTW, I understand Python 2.6.5+ supports class-level decorators, so maybe 
JUnit's BlockRunner-concept can be introduced, removing the dependency on the 
'setUp' method.

I'll be bowing out of the Python world shortly, so I'd be vary happy for you to 
adopt this code and take it in whatever direction you think best.

Cheers, Darren

Original comment by dbisho...@gmail.com on 1 Sep 2010 at 12:06