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 call assertion fails in 1.1.x #283

Closed
miki725 opened this issue Jul 15, 2015 · 9 comments
Closed

Mock call assertion fails in 1.1.x #283

miki725 opened this issue Jul 15, 2015 · 9 comments

Comments

@miki725
Copy link

miki725 commented Jul 15, 2015

Im experiencing a very strange issue with mock>=1.1 which causes mock call assertion to fail in one of my projects:

1) FAIL: test_map_node_expression (tests.test_mapper.TestMapperBase)

   Traceback (most recent call last):
    /Volumes/Data/Users/miki725/.virtualenvs/simplepath/lib/python3.4/site-packages/mock/mock.py line 1299 in patched
      return func(*args, **keywargs)
    tests/test_mapper.py line 365 in test_map_node_expression
      context=mock_get_lookup_context.return_value,
    /Volumes/Data/Users/miki725/.virtualenvs/simplepath/lib/python3.4/site-packages/mock/mock.py line 942 in assert_called_once_with
      return self.assert_called_with(*args, **kwargs)
    /Volumes/Data/Users/miki725/.virtualenvs/simplepath/lib/python3.4/site-packages/mock/mock.py line 931 in assert_called_with
      six.raise_from(AssertionError(_error_message(cause)), cause)
    <string> line 2 in raise_from

   AssertionError: Expected call: mock(sentinel.data, context=<MagicMock name='get_lookup_context()' id='4486874112'>, lut=sentinel.lut, super_root=sentinel.root)
   Actual call: mock(sentinel.data, context=<MagicMock name='get_lookup_context()' id='4486874112'>, lut=sentinel.lut, super_root=sentinel.root)

If you take a look at the assertion error, both calls are actually identical so the mock somehow cant detect that even though it prints identical mock calls in the assertion message.

Test passes perfectly on mock==1.0.x versions but something in mock>=1.1.x causes the test to fail. I tried to replicate the bug by using a dummy example however so far have not been successful. Due to that I cant produce a simple test case which could be included in mock test suite itself and so Ill try to provide all the information I can here and hopefully somebody can either spot what Im doing wrong or confirm the validity of a bug in mock itself.

In order to illustrate the issue better, I setup two branches (below are links to their PRs) in my project:

  • lists - my feature branch where mock is pinned to 1.0.1 and all tests pass
  • mock - branch where I pinned mock to 1.1.3 which causes same tests to fail both locally and in travis.

You can in open mock->lists PR that the only difference is the mock version makes me believe that mock might contain a bug.

Here are corresponding travis jobs for both branches (links to Py3 build however same happens on Py2 as well):

For convenience here are relevant links to code:

Any ideas?

Let me know if you will need any additional information to debug this further.


PS. I had similar results when trying to use Python3 built-in unittest.mock.

@rbtcollins
Copy link
Member

That certainly is odd. I don't suppose you can boil it down to a more pithy example?

@miki725
Copy link
Author

miki725 commented Jul 15, 2015

No. So far was unsuccessful in making a dummy example with the same failure.

@QuLogic
Copy link

QuLogic commented Jul 15, 2015

Not an expert by any means, but how's this?

import mock
#from unittest import mock

print(mock.__version__)

def bar():
    print('bar was called.')
    return 1

def foo():
    print('foo was called.')
    return bar()

print(foo())

with mock.patch('__main__.bar') as pb:
    print(foo())

pb.assert_called()

With mock 1.0.1, the test passes. With mock 1.1.3, the assert fails. With Python 3.4.3 (and altered import), the test passes.

@rbtcollins
Copy link
Member

This fails on Python 3.5/3.6. Filing upstream

@rbtcollins
Copy link
Member

Oh, actually no. @QuLogic your reproducer shows the confusing API - assert_called never existed. The assertion you're seeing is mock detecting you're trying to call an assertion that never existed and failing.

This doesn't tell us anything about @miki725 's failure - sorry.

@QuLogic
Copy link

QuLogic commented Jul 17, 2015

Huh, well at least it might explain ours. :P

@rbtcollins
Copy link
Member

@miki725 if you can't reproduce it thats fine - can you at least verify against Python 3.5 to see if its a backport specific issue or not?

@miki725
Copy link
Author

miki725 commented Aug 13, 2015

sure. Ill try to do that this weekend. my work computer does not have 3.5 installed already...

thakkarparth007 added a commit to thakkarparth007/mailer that referenced this issue Dec 27, 2015
This version is installed on my local system and all the tests
are passed. However, on travis systems, somehow, the tests
aren't passing. Similar problems with mock have been reported
(testing-cabal/mock#283). So, setting
the version to what works locally. Without this, the build fails
because of a call that is made as expected, but mock thinks the
calls are different See:
(https://travis-ci.org/thakkarparth007/mailer/jobs/99008675)
@cjw296
Copy link
Collaborator

cjw296 commented Nov 29, 2018

This repo is only for issues that are specific to the backport.
Please report issues with mock in the upstream bug tracker at https://bugs.python.org/.
Once issues are fixed upstream, they can be backported here.

@cjw296 cjw296 closed this as completed Nov 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants