Michael Foord added the comment:

Yes there are definitely room for documentation improvements.

And, yes - pulling the args out from some_mock.call_args "boils down to doing 
the matching by hand". You only do it when you *want* to do the matching by 
hand.

Your use case I would write:

from mock import Mock, ANY

...
my_mock(1, someobj(), bar=someotherobj())
my_mock.assert_called_with(1, ANY, bar=ANY)

args, kwargs = my_mock.call_args
foo = args[1]
bar = kwargs['bar']

self.assertIsInstance(bar, someobj)
self.assertIsInstance(foo, someotherobj)


It's a *little* cumbersome, but not something I do very often and not much 
extra code. I'm not sure that having "assert_called_with" return objects is an 
intuitive API either. (And having to specify tuple indices in a call to ANY is 
a bit odd too.)

Custom matchers that do the comparison in their __eq__ method would be another 
possibility:

class IsInstance(object):
  def __init__(self, Type):
    self.Type = Type
  def __eq__(self, other):
   return isinstance(other, self.Type)


my_mock.assert_called_with(1, IsInstance(someobj), bar=IsInstance(someotherobj))

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17063>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to