-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
mock.ANY doesn't match mock.MagicMock() object #69382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Since Python 3.5.0 mock.MagicMock() object seems not matched by mock.ANY. This behavior looks weird and breaks tests of boto. Minimized example: In Python 3.4.3:
>>> from unittest import mock
>>> m = mock.MagicMock()
>>> m(mock.MagicMock())
<MagicMock name='mock()' id='139728217270704'>
>>> m.assert_called_with(mock.ANY)
>>>
In Python 3.5.0:
>>> from unittest import mock
>>> m = mock.MagicMock()
>>> m(mock.MagicMock())
<MagicMock name='mock()' id='140093484276536'>
>>> m.assert_called_with(mock.ANY)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.5/unittest/mock.py", line 792, in assert_called_with
raise AssertionError(_error_message()) from cause
AssertionError: Expected call: mock(<ANY>)
Actual call: mock(<MagicMock id='140093520206872'>) |
I've had a look and I think this could be because the class _Call (also in unittest.mock) has lost its __ne__ method between 3.4 and 3.5. Compare This leads me to this changeset: My failing test: from unittest import mock
call1 = mock.call(mock.MagicMock())
call2 = mock.call(mock.ANY) assert call1 == call2 This passes in 3.4 but fails in 3.5, but fails on the second assert, not the first. So they are equal, but they're not not-equal. I've added this as a test and reinstated __ne__ in my patch. |
Looks like _Call is a subclass of tuple. Checks in the test could be written as "self.assertIs(a == b, True)". |
It would be better to use just default implementation: __ne__ = object.__ne__ Interesting that while call1 == call2 is True, call2 == call1 is False. But this is different issue. |
Have added a new diff to just use the default __ne__ implementation rather than tuple's. Have also added a test that targets exactly the reported issue. |
New changeset dcd3b078ab84 by Berker Peksag in branch '3.5': New changeset 880d609b6664 by Berker Peksag in branch 'default': |
Thanks! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: