search

derwiki-adroll / mock

Automatically exported from code.google.com/p/mock
BSD 2-Clause "Simplified" License
0 stars 0 forks source link

[Doc issue] Mock.assert_has_calls doesn't work as expected #165

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The following are two functions that both fail (but shouldn't):

def failing_assertion_magic_mock():
    m = MagicMock()
    expected = []
    for i in range(5):
        expected.append(call(i))
        l = m.from_here(i)
        if l.branch == True:
            print "Should not get here"
    m.from_here.assert_has_calls(expected)

def failing_assertion_mock():
    m = MagicMock()
    expected = []
    for i in range(5):
        expected.append(call(i))
        l = m.from_here(i)
        if l.branch == True:
            print "Should not get here"
    m.from_here.assert_has_calls(expected)

To run just do:

failing_assertion_mock()

failing_assertion_magic_mock()

I expect the assert_has_calls to only inspect the "from_here" method, but 
instead it inspects even the return value's calls so the assertions 
assert_has_calls does not work.

I've tested this on OS X 10.6.8. Using a homebrew of python 2.7.3

Original issue reported on code.google.com by somnium...@gmail.com on 27 Jul 2012 at 10:22

GoogleCodeExporter commented 9 years ago 
mock.assert_has_calls checks against the mock_calls list of a mock - which 
*explicitly* includes calls to child mocks. The documentation could probably be 
clearer on this issue. If you don't want to track calls to __eq__ you could use 
Mock instead of MagicMock. 

You could also set any_order=True in the call to assert_has_calls(...). This 
ignores the extra calls. Or you could use ANY as a placeholder for the errant 
calls.

Original comment by fuzzyman on 27 Jul 2012 at 11:18

GoogleCodeExporter commented 9 years ago 
@fuzzyman Thank you for the clarification. I was about to ask to close this 
issue. I saw in the unit tests for mock that this was a design decision. 
Although, I'm not entirely sure I agree with that design choice, I do see it's 
applicability and appreciate the workarounds. However, it isn't clear in the 
documentation that this is the behavior of assert_has_calls.

Original comment by somnium...@gmail.com on 27 Jul 2012 at 11:25

GoogleCodeExporter commented 9 years ago 
If you *want* to check calls to child mocks then it's a very useful design 
choice. If you don't it isn't I guess...

I'm going to change this issue to a doc clarification task.

Original comment by fuzzyman on 27 Jul 2012 at 11:27