Super Simple Mocking For Python

stch | karma -1 | avg karma -0.04 · 2012-02-23 03:22:11+00:00

Doesn't work as expected when (a) the attribute to be mocked is not part of the module originally (the attribute persists in the symbol table after the mock is destroyed) and (b) if one of the attributes to be mocked is named 'orig'.

jacobolus | karma 24479 | avg karma 3.64 · 2012-02-23 04:21:53+00:00

   self.mocks = dict(zip(args[::2], args[1::2]))

Makes for a very unpythonic feeling API. I’d be interested to hear why the author settled on this design, and see example uses that he likes the look of. Are there any other libraries which use this pattern?

tebeka | karma 383 | avg karma 5.8 · 2012-02-23 04:33:42+00:00

You can either use mock(obj, {'x': 1, 'y': 2}) or mock(obj, 'x', 1, 'y', 2). I thought it'll be nice to provide both options, but you might be right and using just a dict of mocks is more Pythonic.

MBlume | karma 3191 | avg karma 5.49 · 2012-02-23 04:46:20+00:00

At risk of bikeshedding, I think the "most pythonic" approach would be mock(obj, x=1, y=2)

Seriously though, cool lib, thanks for it =)

reply

jacobolus | karma 24479 | avg karma 3.64 · 2012-02-23 06:53:02+00:00

Yes, the most pythonic is:

  mock(obj, x=1, y=2)

Which you get by:

  def __init__(self, obj, **mocks):
      self.obj = obj
      self.mocks = mocks

This can then also be called (using the built-in double-star-unpacking feature) as:

  mock(obj, **{'x': 1, 'y': 2})

or even

  mock(obj, **dict([('x', 1), ('y', 2)]))

Then there’s no explicit need to support multiple alternative function signatures, and in particular you don’t get people using the (quite atypical and therefore semantically ambiguous):

  mock(obj, 'x', 1, 'y', 2).

tebeka | karma 383 | avg karma 5.8 · 2012-02-23 20:50:11

Thanks, updated the code to use keyword arguments only.

has207 | karma 9 | avg karma 1.5 · 2012-02-23 04:40:04+00:00

It'd be really nice if it were this simple, and in a language like Javascript you'd probably succeed. But Python has a lot of pit traps for you when you start monkey patching things. For example, what happens when the attribute you're mocking (though really you should be calling it stubbing since that's all that happens here) is inherited from a superclass and you try to restore it with your dict update approach? What happens to all the other instance of the class?

I'd stick with an existing library that does these things correctly.

reply

johnrob | karma 4286 | avg karma 3.49 · 2012-02-23 05:34:21+00:00

The line where the original attributes are backed up needs to be a deep copy (otherwise the updates will affect the backed up dictionary):

self.orig = self.obj.__dict__

Should be more like:

self.orig = self.obj.__dict__.copy()

reply

surething | karma 48 | avg karma 2.67 · 2012-02-23 09:57:16+00:00

Agreed. I did the following:

    def __enter__(self):
        self.original = dict(self.obj.__dict__)
        self.obj.__dict__.update(self.mocks)
        return self

    def __exit__(self, typ, val, traceback):
        self.obj.__dict__ = self.original

This doesn't perform a deep copy, but prevents modifications on self.obj.__dict__ from modifying self.original also.

noidi | karma 293 | avg karma 8.37 · 2012-02-23 01:13:53

For another clever take on mocking in Python, check out Ian Bicking's minimock: http://blog.ianbicking.org/minimock.html

paolovictor | karma 12 | avg karma 1.71 · 2012-02-24 00:43:51+00:00

I'm getting more intimate with Python and also made a small mocking library, I'm looking for constructive feedback: https://github.com/paolovictor/mockaccino