[TIP] I don't get it?

[Michael Foord]

Hello W W,

Without going into the details it sounds like you might be *over 
mocking*. If you let your code actually make the function calls (rather 
than mocking them) then your tests would very soon tell you if you they 
were being called in the wrong way. Mocking should be used to make your 
life easier rather than harder. If there is functionality your functions 
use that *needs* to be mocked (database / network / filesystem access) 
then mock that layer instead.

I disagree that Python is particularly "dangerous", function signatures 
is only one of a myriad ways that code can fail - and semantic failures 
are *far* more common and harder to catch. Checking that functions are 
called in the correct way is trivially easy as it will be caught simply 
by exercising the call in *any* way - unless you mock them all out...

Alternatively if you need to check that your code is picking the *right* 
functions to call, then mock them out for *those* tests - but leave 
signature checking to another set of tests that call the real functions. 
No reason you need to do it all in a single test.

All the best,

Michael Foord

On 15/11/2010 15:24, WW wrote:
> Thanks for your prompt attention to this.
>
> I have actually noticed some interesting usage patterns when utilizing 
> mock; it seems like there are two types of functionality I am trying 
> to mock, the first is where a module acts as a wrapper for a class or 
> module which performs some sort of external work.  In this case I find 
> myself calling assert_called_with quite a bit because I want the 
> external module to have been directed to do something specific at the 
> completion of the test; failing to do so constitutes a test failure.  
> The second type is when another module acts as a set of utilities for 
> the class I'm testing.  I still want to make sure that the module is 
> called correctly (i.e. not in a way that will cause an error at 
> runtime), but the class being tested has more autonomy to decide which 
> functions are called and how in order to get done whatever it needs to 
> be doing. Specifying all the function calls exactly here makes the 
> test too restrictive and will cause the test code to need to be 
> re-written when something trivial about the class being tested changes.
>
> The second scenario is where I envisioned mocksignature=True coming in 
> handy, but it's still not 100٪ where I want it to be, seemingly due to 
> the limitations of python.  I like python a lot but one has to accept 
> that it's simply a "dangerous" language in which it's hard to make 
> guarantees about whether or not code will work properly, even if one 
> is willing to spend a lot of time writing tests.
>
>    -W.W.
>

-- 

http://www.voidspace.org.uk/

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (½BOGUS AGREEMENTS½) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.