Antoine Pitrou added the comment:
Just got bitten by this again. Context: I have a protocol which is sending JSON
datagrams over the wire and I'm checking the sent data. I can't exactly check
the JSON-encoded content since dict ordering is undefined. So right now I have
to write:
Michael Foord added the comment:
Note that there is nothing stopping you using the mock.ANY and
assert_called_once_with style assert currently. You're making your assert more
clumsy than it needs to be.
With my proposal you could write:
q.tranport.assert_called_once_with(mock.ANY, (PEER,
Antoine Pitrou added the comment:
I still have to do some tuple unpacking myself while assert_* already did it
first. It can be tedious and error-prone (especially if there are several
arguments to get).
If the assert methods returning something bothers you, how about introducing a
new
Michael Foord added the comment:
Or create a JsonMatcher class that does it for you.
class JsonMatcher(object):
def __init__(self, expected):
self.expected = expected
def __eq__(self, other):
return json.loads(other) == self.expected
Michael Foord added the comment:
I still don't particularly like the idea of the assert_* methods returning
something.
If the call args tuples had args and kwargs attributes, for which there are
outstanding feature requests, then you could simply do:
my_mock(1, someobj(), bar=someotherobj())
Antoine Pitrou added the comment:
I think a better possibility would be to return an indexable match object (as
bit like re match objects):
my_mock(1, someobj(), bar=someotherobj()):
match = my_mock.assert_called_with(
1, ANY, bar=ANY)
self.assertIsInstance(match[0], someobj)
New submission from Antoine Pitrou:
assert_called_with currently compares every argument for equality, which is not
very practical when one of the arguments is a complex object, of which you only
want to check certain properties.
It could be very nice if you could write e.g.:
from mock
Michael Foord added the comment:
You mean like mock.ANY ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17063
___
___
Python-bugs-list mailing
Michael Foord added the comment:
Oh, you want the assert_called_with call to *return* the objects compared with
the placeholder?
Well, mock.ANY already exists and you can pull the arguments out for individual
assertions using some_mock.call_args.
args, kwargs = some_mock.call_args
Antoine Pitrou added the comment:
I'm noticing that with multiple ANY keyword arguments, the order in the result
tuple is undefined. So perhaps ANY could be instantiable in those cases where
disambiguation is required:
foo, bar = my_mock.assert_called_with(1, foo=ANY(0), bar=ANY(1))
Antoine Pitrou added the comment:
Ah, well... I agree mock.ANY sounds cool :-)
Perhaps it could be mentioned in the docs for assert_etc.? Otherwise you only
learn about it if you are masochistic enough to read the doc till the end :-)
you can pull the arguments out for individual assertions
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
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17063
___
___
13 matches
Mail list logo
