[TIP] I don't get it?

Michael Foord fuzzyman at voidspace.org.uk
Tue Nov 2 10:10:45 PDT 2010


On 02/11/2010 17:02, WW wrote:
> You may have overlooked this from my earlier e-mail:
>
> Here's a small test case that produces the error in Python 2.6, CentOS 
> 5.5:

Ah, I did overlook that. Thanks, that's perfect.

Your usage below looks fine, so this is almost certainly a bug in 
mocksignature. Thanks for reporting it. I should be able to get it fixed 
quickly. A beta 4 of 0.7.0 is due out soon.

It's actually quite a big release and the biggest task for the final 
release is updating the docs examples, which could take a while. :-(

I'll report back here when I have identified (and hopefully solved) the 
issue.

All the best,

Michael Foord

>
>   1.
>       from mock import patch
>   2.
>   3.
>       class tc(object):
>   4.
>           def meth(a, b, c):
>   5.
>               pass
>   6.
>   7.
>       g = tc()
>   8.
>   9.
>       @patch.object(g, 'meth', mocksignature=True)
>  10.
>       def test_g(patched):
>  11.
>           g.meth(1)
>  12.
>  13.
>       test_g()
>
>
>
> On Tue, Nov 2, 2010 at 1:00 PM, Michael Foord 
> <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>     On 02/11/2010 16:57, WW wrote:
>>     Replacing "@patch.object(g, 'meth', mocksignature=True)" with
>>     "@patch('%s.g.meth' % __name__, mocksignature=True)" produces the
>>     same error.  Am I using this wrong?
>
>     Is this the same traceback you posted earlier?
>
>
>         'SentinelObject' object has no attribute '__call__'
>
>     Can you reproduce this with a minimal example? I've never seen
>     that particular issue before.
>
>
>>
>>     Thanks for the clarification regarding spec vs mocksignature.  So
>>     if I wanted to do both (a mock class that raises attribute errors
>>     when invalid attributes are accessed, but actual method
>>     attributes return methods that enforce the correct number of
>>     parameters), do I have to set that up manually, or does spec use
>>     mocksignature internally when returning attribute values?
>>
>
>     Using mocksignature changes the way that you access the mock. As
>     the methods are replaced with 'real function objects' not mock
>     objects as they normally are, you have to do it explicitly. You
>     could create a utility function to auto patch out a mock with
>     mocked-signatures.
>
>     spec is purely about checking attribute access is valid.
>
>
>     All the best,
>
>     Michael Foord
>
>>     Thanks again...
>>
>>     On Tue, Nov 2, 2010 at 12:49 PM, Michael Foord
>>     <fuzzyman at voidspace.org.uk <mailto:fuzzyman at voidspace.org.uk>> wrote:
>>
>>         On 02/11/2010 16:43, WW wrote:
>>>         On Tue, Nov 2, 2010 at 12:17 PM, Michael Foord
>>>         <fuzzyman at voidspace.org.uk
>>>         <mailto:fuzzyman at voidspace.org.uk>> wrote:
>>>
>>>             On 02/11/2010 15:34, WW wrote:
>>>>             Hello,
>>>>
>>>>             This is my first time using the python mock library and
>>>>             I'm a little confused.  I'd like to provide some
>>>>             guarantees that my mocks are being called with the
>>>>             correct number of arguments.  The documentation seems
>>>>             to indicate there are two ways to do this, "spec" and
>>>>             "mocksignature", but it's a little unclear to me what
>>>>             the difference is supposed to be between them.
>>>>
>>>>             I find myself using the @patch.object decorator almost
>>>>             all the time, because the modules I'm testing use a lot
>>>>             of top-level functions from modules they've imported. 
>>>>             When I do something like this:
>>>>
>>>>             @patch.object(somemodule, 'somemethod', spec=True)
>>>>
>>>
>>>             You should still be able to use patch with a named
>>>             function (as a string). See the other replies for an
>>>             example.
>>>
>>>
>>>         Does this work if I'm trying to patch a global variable
>>>         rather than a function in another module?
>>
>>         You mean a global variable in the current module? If so then
>>         still yes.
>>
>>         @patch('%s.function' % __name__, mocksignature=True)
>>         def test_something(self, mockfunction):
>>             ...
>>
>>
>>
>>>
>>>>             It doesn't seem to have any effect; I can call
>>>>             somemodule.somemethod with any combination of invalid
>>>>             arguments and no exceptions are thrown. 
>>>
>>>             Using spec doesn't protect you against being called with
>>>             invalid arguments. You should get an error when you
>>>             validate that the calls were made correctly when you
>>>             call 'assert_called_with'.
>>>
>>>
>>>         assert_called_with is fine if I know the exact values I want
>>>         the function to be called with, but I'm just trying to make
>>>         sure that a function was called with the correct number of
>>>         arguments.  If spec can't do this, then what is spec
>>>         supposed to be used for?  I'm still unclear as to what the
>>>         difference is between spec and mocksignature and why both exist.
>>
>>         spec is not for mocking functions (mocksignature is). Spec is
>>         for mocking out classes / objects to check that only methods
>>         / attributes that exist on the spec object are used.
>>         Accessing other attributes will raise an AttributeError.
>>
>>
>>         All the best,
>>
>>         Michael Foord
>>
>>>>             However, when I do:
>>>>
>>>>             @patch.object(somemodule, 'somemethod', mocksignature=True)
>>>>
>>>>             I get:
>>>>
>>>>             Traceback (most recent call last):
>>>>               File "/usr/lib/python2.6/site-
>>>>             packages/mock-0.7.0b3-py2.6.egg/mock.py", line 485, in
>>>>             patched
>>>>                 arg = patching.__enter__()
>>>>               File
>>>>             "/usr/lib/python2.6/site-packages/mock-0.7.0b3-py2.6.egg/mock.py",
>>>>             line 536, in __enter__
>>>>                 new_attr = mocksignature(original, new)
>>>>               File
>>>>             "/usr/lib/python2.6/site-packages/mock-0.7.0b3-py2.6.egg/mock.py",
>>>>             line 140, in mocksignature
>>>>                 signature, func = _getsignature(func, skipfirst)
>>>>               File
>>>>             "/usr/lib/python2.6/site-packages/mock-0.7.0b3-py2.6.egg/mock.py",
>>>>             line 87, in _getsignature
>>>>                 func = func.__call__
>>>>             AttributeError: 'SentinelObject' object has no
>>>>             attribute '__call__'
>>>>
>>>
>>>             This is weird. The traceback implies that you are trying
>>>             to replace a sentinel object using mocksignature (and
>>>             sentinels don't have signatures to mock). Either that or
>>>             it is a bug. I'll create a simple test case here (but
>>>             this functionality *is* tested), but it looks like
>>>             something is not quite setup how you expect.
>>>
>>>
>>>         Here's a small test case that produces the error in Python
>>>         2.6, CentOS 5.5:
>>>
>>>           1.
>>>               from mock import patch
>>>           2.
>>>           3.
>>>               class tc(object):
>>>           4.
>>>                   def meth(a, b, c):
>>>           5.
>>>                       pass
>>>           6.
>>>           7.
>>>               g = tc()
>>>           8.
>>>           9.
>>>               @patch.object(g, 'meth', mocksignature=True)
>>>          10.
>>>               def test_g(patched):
>>>          11.
>>>                   g.meth(1)
>>>          12.
>>>          13.
>>>               test_g()
>>>
>>>
>>>
>>>             All the best,
>>>
>>>             Michael Foord
>>>
>>>
>>>         Likewise.
>>>
>>>>             What am I missing here?
>>>>
>>>>             Thanks for your help.
>>>>
>>>>
>>>>             _______________________________________________
>>>>             testing-in-python mailing list
>>>>             testing-in-python at lists.idyll.org
>>>>             <mailto:testing-in-python at lists.idyll.org>
>>>>             http://lists.idyll.org/listinfo/testing-in-python
>>>
>>>
>>>             -- 
>>>             http://www.voidspace.org.uk/
>>>
>>>
>>
>>
>>         -- 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.
>>
>>
>
>
>     -- 
>
>     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.
>
>


-- 

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20101102/1501990e/attachment-0001.htm>


More information about the testing-in-python mailing list