Skip to content
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

mock.ANY doesn't match mock.MagicMock() object #69382

Closed
felixonmars mannequin opened this issue Sep 20, 2015 · 7 comments
Closed

mock.ANY doesn't match mock.MagicMock() object #69382

felixonmars mannequin opened this issue Sep 20, 2015 · 7 comments
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@felixonmars
Copy link
Mannequin

felixonmars mannequin commented Sep 20, 2015

BPO 25195
Nosy @voidspace, @berkerpeksag, @serhiy-storchaka, @felixonmars
Files
  • fix_mock_call_ne.patch
  • 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:

    assignee = None
    closed_at = <Date 2016-03-27.21:29:41.270>
    created_at = <Date 2015-09-20.10:27:20.336>
    labels = ['type-bug', 'library']
    title = "mock.ANY doesn't match mock.MagicMock() object"
    updated_at = <Date 2016-03-27.21:30:10.932>
    user = 'https://github.com/felixonmars'

    bugs.python.org fields:

    activity = <Date 2016-03-27.21:30:10.932>
    actor = 'berker.peksag'
    assignee = 'none'
    closed = True
    closed_date = <Date 2016-03-27.21:29:41.270>
    closer = 'berker.peksag'
    components = ['Library (Lib)']
    creation = <Date 2015-09-20.10:27:20.336>
    creator = 'felixonmars'
    dependencies = []
    files = ['41848']
    hgrepos = []
    issue_num = 25195
    keywords = ['patch', '3.5regression']
    message_count = 7.0
    messages = ['251162', '259811', '259814', '259822', '259835', '262538', '262539']
    nosy_count = 6.0
    nosy_names = ['michael.foord', 'python-dev', 'berker.peksag', 'serhiy.storchaka', 'felixonmars', 'aplummer']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue25195'
    versions = ['Python 3.5', 'Python 3.6']

    @felixonmars
    Copy link
    Mannequin Author

    felixonmars mannequin commented Sep 20, 2015

    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'>)

    @felixonmars felixonmars mannequin added stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Sep 20, 2015
    @aplummer
    Copy link
    Mannequin

    aplummer mannequin commented Feb 8, 2016

    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
    https://hg.python.org/cpython/file/v3.4.4/Lib/unittest/mock.py#l2010
    with
    https://hg.python.org/cpython/file/v3.5.1/Lib/unittest/mock.py#l2028

    This leads me to this changeset:
    https://hg.python.org/cpython/rev/3603bae63c13

    My failing test:

    from unittest import mock
    
    call1 = mock.call(mock.MagicMock())
    call2 = mock.call(mock.ANY)

    assert call1 == call2
    assert not (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.

    @berkerpeksag
    Copy link
    Member

    Looks like _Call is a subclass of tuple. Checks in the test could be written as "self.assertIs(a == b, True)".

    @serhiy-storchaka
    Copy link
    Member

    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.

    @aplummer
    Copy link
    Mannequin

    aplummer mannequin commented Feb 8, 2016

    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.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Mar 27, 2016

    New changeset dcd3b078ab84 by Berker Peksag in branch '3.5':
    Issue bpo-25195: Fix a regression in mock.MagicMock
    https://hg.python.org/cpython/rev/dcd3b078ab84

    New changeset 880d609b6664 by Berker Peksag in branch 'default':
    Issue bpo-25195: Fix a regression in mock.MagicMock
    https://hg.python.org/cpython/rev/880d609b6664

    @berkerpeksag
    Copy link
    Member

    Thanks!

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants