jsatt / mock Goto Github PK

=== Change ===
The following syntax could be supported

with patch('blah.blah', new):
    test stuff

with patch('blah.blah') as mockThing:
    test stuff involving mockThing

patch would still work as a function decorator

------------------------

=== Rationale ===

One often has patterns like this:

def test(self):
    s = something computed (e.g for side-effects, logging etc)
      which you don't want to / can't compute in the module scope
    @patch('blah.blah.blah', s)
    def f():
       do stuff
     f()

These are bad because:
* They are hard to read
* It's easy to forget to call f
* They confuse the order of execution of the function - you have to 
     work out that the code within the function is not executed.
     Other people may have intelligent subconscious parsing but
     mine is exceedinly dim.

If patch became a with context this becomes

def test(self):
    s = something computed (e.g for side-effects, logging etc)
      which you don't want to / can't compute in the module scope
    with patch('blah.blah.blah', s):
       do stuff

which has fewer failings - although it still increases the level of
indentation.

Also with patchings allow you to move your patching around, perhaps
creating greater 'symmetry' by placing your patching near the part of your
test that uses it.

When creating a Mock with a spec, the __repr__ should include the class name of 
the spec by default, either just setting a default for name or in addition to 
it.

Hello,

It would be nice if you could patch non-existing attributes with @patch.

When the function ends you could delete the attribute.

I have included a patch for this.

-- 
Christos Trochalakis

Copying an instance of a Mock object with the copy module breaks the function 
of coverage for subsequent lines of code.

Win32 Python 2.5.4

Latest mock (0.7something)

Latest coverage snapshot but old versions of it do it too, like the ancient 
version that comes with eclipse pydev.

I opened a ticket in coverage as well: 
http://bitbucket.org/ned/coveragepy/issue/93/copying-a-mock-object-breaks-covera
ge#comment-262518

Suggested by Stéphane Blondon (http://www.yaal.fr )

I'm reluctant to add more methods, but open to seeing what other people think.

For this use case you can use "assert mock.call_count == 1" or similar.

When using Mock with a spec, the __getattr__ method raises AttributeErrors on 
unknown attributes, the __setattr__ method does not at the moment.

This patch allows to run 

python setup.py build_sphinx

It assumes setuptools / distribute is available and adds a setup dependency on 
sphinx.

Using distutils, this does not work, but does no harm either (distutils doesn't 
know the build_sphinx command)

On python 2.6 I tried to use KeyboardInterrupt as Mock.side_effect. But it
didnt work. The problem seems that it checks if the side_effect is an
"Exception" instead of a "BaseException"

Hi Michael,

I'm investigating Mock for roll-out in our company. My target users
generally are python beginners. For them, even trivial things can make
installation impossible. Therefore I would like to suggest a slight
rewording of the installation instructions to make it clear that either pip
or easy_install is required to install the package (patch attached). 

Another thing: how do I rebuild the documentation? At work I use a
setup.cfg with the neccessary bits so that 

python setup.py build_sphinx 

does the right thing.
If you are interested, I can share that file.

Regards,
Florian

From Konrad Delong.

I just had an Idea for improvement for mock library: I often switch
between using patch and patch_object. That makes me change the imports
each time as well. There's an elegant solution for that. Say what you
think:

@patch.object(SomeClass, 'classmethod')
def test_something(self, mockMethod):
    SomeClass.classmethod(3)

This way you need to have only one import, and it still reads well.

A diff against svn revision 120 is included.

In one of my unit tests I wanted to ensure that a try catch was working in the 
method I was 
testing. 

I am patching my test with:
@patch(ldap.ldapobject.SimpleLDAPObject, 'simple_bind_s', foo)

I may be missing an existing way to specify what actually happens when foo is 
called, (maybe it 
should actually just accept a function to solve this for the general case*) but 
I figured specifying 
an exception to raise would be keeping in line with specifying a value to 
return.

I've attached a patch for your review if you're so inclined.

* I've also included a patch which includes accepting a function reference. It 
should be pretty self 
explanatory. Of course, it's possible to raise the exception as part of 
providing a function 
callback, but I like the parity with the simple property for retrun_value

Hope these are of some use to you, I may be completely missing some grander 
vision, so let me 
know if you know of some better way to have a stubbed object call some function 
or raise some 
exception and not just return a value.

Seems to make sense now that class decorators made it into Python 2.6

When calling mock with mutable object and then change it

from mock import Mock

a = set([1, 2, 3])

mock_object = Mock()
mock_object(a)

a.update([3, 4])
mock_object(a)

print mock_object.call_args_list

It requires attention ( i was surprised with failing tests )
Maybe it could be fixed by copying parameters in mock calls and hold them
internal.

For most cases the wrapped objects would work just as expected, but they would 
have additional tracking data attached.

@mock.wrap('sys.stdin')
def foo(wrapped_stdin):
    do_sth()
    assert wrapped_stdin.called

Test under Python 3. Ideally a single codebase.

Mock.py makes use of the deprecated % formatter. Eg:

  Line 31: return '<SentinelObject "%s">' % self.name

In Python 3.2 this will stop working. Switching to str.format() formatter will 
prevent this:

  Line 31: return '<SentinelObject "{0}">' % self.name

This will work with Python 2.6 too

What version of the product are you using? On what operating system?
I'm using Python 2.6 and 3.1, but problem won't be there till Python 3.2. 

Please provide any additional information below.

  I just patched a copy or Mock.py in my bitbucket repository so that all formatters are up to date.   
  You can see the diffs here:

  http://bitbucket.org/gregmalcolm/python_koans/diff/python%203_1/libs/mock.py?
diff2=c79408a270ae&diff1=23684222844d

Man of the tests I write need to simulate iterative calls into the same 
functions. I have coded up 
an interface which enables this:

* raises -- call object is called it raises after the side_effect. I think this 
nicely separates 
exceptions from change of global state.
* return_iter -- an iterator object which returns next() on successive calls to 
the mock object.
* return_func -- return the value from the passed in callable.

Pros: useful new features.
Cons: The interface overlaps a bit since only one of the returns will actually 
happen and it's not 
clear if side_effect should be called before or after raises. For simplicity, I 
chose to isolate what 
to return so side_effect is always still called. Any ordering of raises, 
return_iter, and return_func 
prior to calling to return_value as the new return value will keep the API 
backward compatible. I 
do not think the overlapping API here matters since no one will construct an 
object with both a 
return_value and a return_iter.  This could be addressed with an assert 
statement.

This patch adds a new patch command called 'patch_new'. 

This command patches the __new__ of the target class in order to return a
Mock instead of a real instance of the class. 

Notes:
  * The patch for issue 21 must be applied first. 
  * The patch_new works only on new style classes.
  * The patch includes the patch_new's tests.


Why doing that?
===============

With 'patch' or 'patch_obj' the target class is patched by changing the
attribute (the class' reference) in the module. But the patch may not be
applied if the class and the module have been already imported by Python.

This case often comes up when you want to Mock a class B used in methods of
the class A under tests. See mock-demo-patchnew.zip to recreate the issue.

The file mock-demo-patchnew.zip illustrates the motivation for this feature
(see test_patch which fails VS test_patchnew).


Syntax
======

  patch_new(class)
  patch_new(class, mock)


Example
=======

In tests_adapter.py

from hardware import Hardware
from adapter import Adapter

@patch_new(Hardware)  
def testAdapter(self):
     << From this point, all call to Hardware() in the 
     << flow will return a Mock.

    self.adapter.method_which_calls_Hardware()

It would be great if there was a support for using mock in two steps, like this;
{{{
class TestSth(TestCase):
    def setUp(self):
        self._original_state = mock.setup_mocking("sys.stdin")
    def tearDown(self):
        mock.teardown_mocking(self._original_state)
}}}

If you want to patch (for example) sys.stdout with a cStringIO then you want a 
new one created rather having to pre-create it.

Daryl Spitzer suggests adding a "new_callable" keyword argument to patch, which 
could be used thusly:

[code]
    def testPatchWithNewCallable(self):
        """verify patch works with new_callable=True"""
        import sys

        ERROR = 'test'
        def makes_error():
            print >> sys.stderr, ERROR

        import cStringIO

        @patch('sys', 'stderr', new=cStringIO.StringIO, new_callable=True)
        def confirm_expected_error(expected_error):
            makes_error()
            self.assertEquals(sys.stderr.getvalue(), expected_error,
                              'unexpected value from mock stderr')

        confirm_expected_error('%s\n' % ERROR)
        # this second call will fail unless new_callable=True in the patch
        confirm_expected_error('%s\n' % ERROR)
[/code]

- track everything in method_calls, eg:

>>> m = Mock()
>>> m()
<Mock ...>
>>> m.method_calls
[('__call__',)]

...so I don't have to check m.call_args_list *and* m.method_calls to make
sure that nothing has been called on m itself that shouldn't have been.

Probably requires a custom metaclass.

When an attribute is patched twice on the same block (with @patch or with),
the patch is not completely restored at the end of the block.

Example:

@patch_object('test.something', a_mock)
@patch_object('test.something', a_mock)
def example

See issue 26 [1].

[1] http://code.google.com/p/mock/issues/detail?id=26

I've seen this happen with some parts of django (djangoproject.com), as well as 
homebrew 
iterable objects.

Calling

mock = Mock(spec=IterableClass)

will indeed provide a mock object made of that class, but trying things like

"a" in mock

will cause an exception as follows:

"TypeError: argument of type 'Mock' is not iterable"

See below (note that it would be better if all examples used the singular 
assertEqual):


original = SomeClass.attribute
@patch_object(SomeClass, ’attribute’, sentinel.Attribute)
def test():
    self.assertEquals(SomeClass.attribute, sentinel.Attribute, "class attribute not test()
    self.assertEquals(SomeClass.attribute, original, "attribute not restored")


from the
Mock Documentation pdf
Release 0.6.0
August 22, 2009

The following would be my idea of heaven:

>>> m = Mock()
>>> m.heap().stat.dump('somepath')
<Mock ...>
>>> m.objects_and_calls
["m.heap().stat.dump('somepath')"]

No idea how to do this one, but the current way feels a bit icky:

# h.heap().stat.dump('somepath')
self.assertEqual(h.method_calls,[('heap',(),{})])
h = h.heap.return_value
self.assertEqual(h.method_calls,[('stat.dump', ('somepath',),{})]) 

When using multiple @patch decorators, it can get confusing to define your 
arguments in reverse order.  There are two ways I think this could be improved:

A) Reverse the set of args that are appended to the function call.

B) Pass the args in as kwargs instead.  The key could be the attribute name.

Both of these possibilities are backward incompatible though, unless a flag 
were provided.

Currently, it's not possible to have getattr on mock objects raise an exception.

This is possible with magic mathods patching (soon to be released), but owuld 
be quite generic. We could give this additional interface.
{{{
# we want obj.attribute to blow up
obj.side_effect("attribute", RuntimeError)
}}}

This solution brings some magic, but I'm giving it for others to consider.

I've really been enjoying using Mock for my tests, it's a lot easier
than the record/replay style of pymock et al.

One thing that keeps tripping me up when I haven't used it for a
while:

If you patch a class, and then set a return_value on one of its
methods, that return_value is *not* used by instances of that class -
because they aren't really instances of that class.  The correct thing
to do is to patch the method in question directly.

Maybe this should be spelled out more clearly in the docs?
Something like the following:

=================================================================

Consider this function and naively-written test case:

def something():
    import httplib2
    http = httplib2.Http()
    return http.request('http://example.com', 'POST', headers={}, body='test')

class TestFoo(TestCase):

    @mock.patch('httplib2.Response')
    @mock.patch('httplib2.Http')
    def test_something_bad(self, mock_http, mock_response):
        response = mock_response()
        # I wrongly expect this return value to be used by bound methods.
        mock_http.request.return_value = (response, 'hello POST world')
        # This test fails!
        self.assertEqual(something(), (response, 'hello POST world'))

The reason the test fails is that there's nothing special about
instantiating a class that's been replaced by @patch.  Calling a
patched class is just like calling any other Mock; it returns a new
Mock instance which doesn't know anything about return values of
attributes of its creator.

The correct way to write the test is to patch the method in question directly:

    @mock.patch('httplib2.Response')
    @mock.patch('httplib2.Http.request')
    def test_something_good(self, mock_request, mock_response):
        response = mock_response()
        mock_request.return_value = (response, 'hello POST world')
        self.assertEqual(something(), (response, 'hello POST world'))

========================================================


Alternatively, I think it might be possible for instantiating a mocked
class to work as I expected, eg. if we had a subclass of Mock that
returned a copy of itself when called. Or something like that.  But I
haven't looked into the Mock implementation enough to know if that
would cause problems with other Mock features.

It'd be handy for each of the list-type data structrues to also have a
print_ method, eg:

>>> m = Mock()
...
>>> m.print_method_calls()
(blah,)
(blah,)
(blah,)

...rather than having to do the following in DocTests:

>>> from pprint import pprint
>>> pprint(m.method_calls) 

Need to check that the following issue with the documentation is fixed:

It is about docs
in changelog :
"Nested patches may now be applied in a different order (created mocks
passed in the opposite order). This is actually a bugfix."

in docs :
@patch('Module.ClassName1')
@patch('Module.ClassName2')
def testMethod(self, MockClass1, MockClass2):
    ClassName1()
    ClassName2()
    self.assertEquals(MockClass1.called, "ClassName1 not patched")
    self.assertEquals(MockClass2.called, "ClassName2 not patched")

I think it should be
def testMethod(self, MockClass2, MockClass1):

I got caught out today when using a Mock to wrap an instance of a class where 
one of the wrapped 
methods calls another method on the same class which I was trying to set the 
return value for.  The 
problem is that if I then want to test the first method, the underlying method 
is called and that is 
bound to the actual wrapped class instance.  When the nested call is made it is 
then made against 
the wrapped class not the top-level mock.  

I'm attaching a file showing how this can be worked around with a helper 
function, but perhaps 
something like this could actually be integrated to the main Mock class?  Not 
sure what the 
implications would be but would b e  interested to here what you think.

Should maintain compatibility with Python 2.4.

Will simplify mocks that raise exceptions.

- make method_calls only as verbose as it needs to be, eg:

>>> m = Mock()
>>> m.something()
<Mock ...>
>>> m.method_calls
[('something',)]
>>> m.something('different')
<Mock ...>
>>> m.method_calls
[('something',),('something',('different',))]
>>> m.something('different',some='more')
<Mock ...>
>>> m.method_calls
[('something',),('something',('different',)),('something',('different',),{'some'
:'more')]
>>> m = Mock()
>>> m.something(x=1)
<Mock ...>
>>> m.method_calls
[('something',{'x':1})]

I don't see the empty tuples and dicts as adding anything but they can
cause bracket blindness ;-)

What steps will reproduce the problem?
1. import mock
2. help(mock)

What is the expected output? What do you see instead?

help should output something like:

NAME
    Mock

FILE
    /lib/python2.5/site-packages/...

MODULE DOCS
    ...

CLASSES

    ...

Instead the following exception is raised:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/stephen/lib/python/peopleproject/lib/python2.5/site.py", line
457, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/lib/python2.5/pydoc.py", line 1647, in __call__
    self.help(request)
  File "/usr/lib/python2.5/pydoc.py", line 1691, in help
    else: doc(request, 'Help on %s:')
  File "/usr/lib/python2.5/pydoc.py", line 1482, in doc
    pager(title % desc + '\n\n' + text.document(object, name))
  File "/usr/lib/python2.5/pydoc.py", line 324, in document
    if inspect.ismodule(object): return self.docmodule(*args)
  File "/usr/lib/python2.5/pydoc.py", line 1071, in docmodule
    inspect.getclasstree(classlist, 1), name)]
  File "/usr/lib/python2.5/inspect.py", line 656, in getclasstree
    for parent in c.__bases__:
TypeError: 'SentinelObject' object is not iterable

What version of the product are you using? On what operating system?

Mock 0.6.0/Python 2.5.4 running on Ubuntu linux.

A way of temporarily adding or changing items in a dictionary purely within the 
scope of the test. e.g. for modifying os.environ.

Would take a copy of the dict before patching and then clear and restore the 
dictionary on exit.

{{{

@patch.dict(os.environ)
def test_something():
    os.environ['foo'] = 'bar'

@patch.dict(os.environ, ('key', 'value'), ('key2', 'value2'))
def test_something():
    assert os.environ['key'] == 'value'
}}}

I'm trying to install mock trough easy_install, like:
sudo easy_install -Z mock
(I'm running Kubuntu 7.10 with python2.5)

I get and quiet error:
Sorry: TypeError: ('compile() expected string without null bytes',)

And the hole output is:
$ sudo easy_install -Z mock
Searching for mock
Reading http://cheeseshop.python.org/pypi/mock/
Reading http://www.voidspace.org.uk/python/mock.html
Page at http://cheeseshop.python.org/pypi/mock/ links to .py file(s)
without version info; an index scan is required.
Scanning index of all packages (this may take a while)
Reading http://cheeseshop.python.org/pypi/
Reading
http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?section=python&file=moc
k-0.3.1.zip
Reading http://cheeseshop.python.org/pypi/mock/0.3.1
Best match: mock 0.3.1
Downloading
http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?section=python&file=moc
k-0.3.1.zip#egg=mock-0.3.1
Processing downman.py
Running setup.py -q bdist_egg --dist-dir
/tmp/easy_install-nNB3sU/egg-dist-tmp-4_r8-N
Sorry: TypeError: ('compile() expected string without null bytes',)
zip_safe flag not set; analyzing archive contents...
Sorry: TypeError: ('compile() expected string without null bytes',)
Adding mock 0.3.1 to easy-install.pth file

Installed /usr/lib/python2.5/site-packages/mock-0.3.1-py2.5.egg
Processing dependencies for mock
Finished processing dependencies for mock

Well, your downman.py gives always zip file, but easy_install expects
egg file. Could someone provide a proper egg file for this? Unfortunetly i
don't know setuptools, so i'm not able to do it myself.

BTW I's very good module!

This is more a "philosophical" issue, rather than a coding one.

1) "mock" is really a generic name. Look for "mock", and you'll find dozens of 
unrelated results. Search for "python mock", and you'll probably find out info 
about many different python mock frameworks/tookit/libraries... or the *other* 
python mock project (see point 2)

2) the "mock" name was already taken by Fedora Mock, which is a totally 
different tool (it's a chroot-helper for building rpms, in fact) which is 
written - guess it - in Python:

https://fedorahosted.org/mock/

Fedora Mock seems to have started way before this mock ( 2005 vs end of 2007 ). 
They didn't claim a cheeseshop entry because it's a bit out of their scope - it 
requires quite a bit of configuration beyond the python module - , but 
nonetheless this clash makes it difficult to install both projects on the same 
workstation.



Please: let us look for python mock easily by choosing a new name!

They used to be passed from outermost to innermost, but now it's the other
way around.  I think the original ordering makes more sense, but it could
be argued either way.  The main issue is that this makes upgrading painful.
 Patch attached.

The new test in the patch is not as necessary since the other test catches
the problem, but I didn't find the existing test until I fixed my new one.

What steps will reproduce the problem?
1. When a mock object is used as a ContextManager, the __exit__ method
returns a True value (well, I'm assuming its a Mock object) which results
in an exception being ignored. While this behavior is consistent with the
other methods in Mock, it seems like it could be dangerous from a testing
perspective.

Here is a basic example. In my real scenario, I'm mocking a function that
gets called by the function being tested which later ends up raising an
exception that gets ignored because its inside a with statement.

from __future__ import with_statement
import mock

with mock.Mock() as mymock:
    raise Exception
    print 'after exception was raised'
print 'outside with statement'


What is the expected output? What do you see instead?
The statement "outside with statement" is printed. I would expect a
traceback to be printed due to the raised exception.


What version of the product are you using? On what operating system?
0.4.0, linux

Please provide any additional information below.

>>> from mock import Mock
>>> m = Mock()
>>> str(m)
'<mock.Mock object at 0x6a2d0>'
>>> unicode(m)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: coercing to Unicode: need string or buffer, Mock found
>>> str(m)
'<mock.Mock object at 0x6a2d0>'
>>> 

>>> import mock
>>> mock.__version__
'0.4.0'


Hopefully adding a __unicode__ method will rectify this.

With patch and patch_object, it is not easy to patch an object that is already 
directly imported in the current module (see example below).

In order to achieve that you must write something like:
  @patch_object(sys.modules[__name__], 'target_fnc')

This is because patch_object patches the reference in the target's module but 
not in the current module.

So I wrote a quick function (patch_import) that do it for you. The patch is 
attached with the proper test case. See the example below. 

========
from themodule import target

@patch('themodule.target')
def foo(mock):
  pass # WILL NOT WORK

@patch_import('target')
def bar(mock):
  pass # OK
========

This needs looking into; patch may be broken when patching a class
attribute on an instance (when replacing it would set on the instance not
on the class) and also when patching static methods on classes (they become
unbound methods instead of static methods when replaced).

Consider the following test:

    def test_foo(self):
        m = mock.Mock()
        m.foo.assert_called_with('bar')

This (obviously) fails, but with this, sometimes not so obvious at first 
glance, error:

FAIL: test_foo (__main__.TestFoo)
----------------------------------------------------------------------
Traceback (most recent call last):
...
AssertionError: Expected: (('bar',), {})
Called with: None


I propose a patch which check first that the attribute has been called at least 
once, and display an explicit message if it has failed to do so:


FAIL: test_foo (__main__.TestFoo)
----------------------------------------------------------------------
Traceback (most recent call last):
...
AssertionError: Expected: (('bar',), {})
But not yet called.


I'm not sure if the wording fits you, but I hope you get the idea.

What steps will reproduce the problem?

now = datetime.datetime.now()

class ATestCase(unittest.TestCase):

    @patch('datetime.datetime')
    @patch('urllib2.urlopen')
    @patch_object(RssChannel, 'objects')
    def test_something(self, datetime_mock, urllib2_urlopen_mock, 
rsschannel_mock):

        datetime_mock.now.return_value = now
        print datetime.datetime.now()

        print urllib2_urlopen_mock
        print rsschannel_mock

Seems only to patch the first modules method not.


What is the expected output? What do you see instead?

I expect to call datetime.datetime.now() and get the datetime assigned with 
now

Have already send you this by mail a while back, but thought it would be
handy to also have it registered here in google code.

The patch allows using a Mock to raise an exception and thus test how your
code responds to exceptions.

For example:
>>> mock = Mock()
>>> mock.raised_exception = IOError('Mocking a file that cannot be openend')
>>> mock()
Traceback (most recent call last):
    ...
IOError: Mocking a file that cannot be openend

What steps will reproduce the problem?
1. On the second line of page 8 of mock-0.7.0b2.pdf the following can be seen :

  mock.method_calls == [(’method’,), (’method’, (1, 2)), (’method’, {"a":

What is the expected output? 

   mock.method_calls == [(’method’,), (’method’, (1, 2)), (’method’, {"a":"b"})]

What version of the product are you using? On what operating system?

The file is mock-0.7.0b2.pdf

Please provide any additional information below.

This patch adds a test to verify that two overlapped 'patch' commands using
'with' statements are working fine.

Example:

  with patch('foo', m1):
    with patch('bar', m2):
      # Both are patched
  #Both are unpatched

I added this test to help me debugging a bug for the issue 27. The test
passed but it can help to prevent regressions in the future.

Note: It may be necessary to apply the patch for issue 21 before.