[TIP] Is this a bug in unittest.mock, or am I missing something?
harry.percival at gmail.com
Thu Feb 16 00:52:00 PST 2017
I think the call() objects you create for the expected and the ones used in
the repr of the actuals it's being compared with arent actually the same
type of thing.
Try a print(type(call())) and a print(type(c) for c in
On Tue, 14 Feb 2017, 18:00 John W, <jwdevel at gmail.com> wrote:
> I encountered my problem in Python3.4's unittest.mock, but I imagine
> people on this list might be able to help (is there a better place?).
> I made a SO post about this, too, but haven't seen much movement
> Basically, `assert_has_calls` seems to be behaving in a strange way,
> or else I am misunderstanding something - which is entirely possible,
> as I'm new to unittest.mock.
> I have some fairly small code that repro's the issue:
> $ cat test.py
> from unittest.mock import patch, call
> class Foo:
> def __init__(self):
> def my_method(self, value):
> def test_foo():
> with patch('test.Foo', autospec=True) as MockFoo:
> # Note: in the real code, this usage of Foo is off in some
> other module.
> # Just putting it here for compactness.
> m = Foo()
> MockFoo.assert_has_calls([call(), call().my_method(123)])
> $ py.test test.py
> ... <snip long output> ...
> E AssertionError: Calls not found.
> E Expected: [call(), call().my_method(123)]
> E Actual: [call(), call().my_method(123)]
> The list of calls seems to match exactly, yet the assert fails.
> What's going on, here?
> Oddly, if I remove the 'value' parameter of my_method (and the
> corresponding 123 inputs), it works fine.
> Also, if I do it this way instead, everything works:
> r = MockFoo.return_value
> That makes sense to me, but I don't understand why it would be
> different from the original case.
> ... Help?
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
+44 78877 02511
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the testing-in-python