Asserting successive calls to a mock method

assert_has_calls is another approach to this problem.

From the docs:

assert_has_calls (calls, any_order=False)

assert the mock has been called with the specified calls. The mock_calls list is checked for the calls.

If any_order is False (the default) then the calls must be sequential. There can be extra calls before or after the specified calls.

If any_order is True then the calls can be in any order, but they must all appear in mock_calls.

Example:

>>> from unittest.mock import call, Mock>>> mock = Mock(return_value=None)>>> mock(1)>>> mock(2)>>> mock(3)>>> mock(4)>>> calls = [call(2), call(3)]>>> mock.assert_has_calls(calls)>>> calls = [call(4), call(2), call(3)]>>> mock.assert_has_calls(calls, any_order=True)

Source: https://docs.python.org/3/library/unittest.mock.html#unittest.mock.Mock.assert_has_calls

Usually, I don't care about the order of the calls, only that they happened. In that case, I combine assert_any_call with an assertion about call_count.

>>> import mock>>> m = mock.Mock()>>> m(1)<Mock name='mock()' id='37578160'>>>> m(2)<Mock name='mock()' id='37578160'>>>> m(3)<Mock name='mock()' id='37578160'>>>> m.assert_any_call(1)>>> m.assert_any_call(2)>>> m.assert_any_call(3)>>> assert 3 == m.call_count>>> m.assert_any_call(4)Traceback (most recent call last):  File "<stdin>", line 1, in <module>  File "[python path]\lib\site-packages\mock.py", line 891, in assert_any_call    '%s call not found' % expected_stringAssertionError: mock(4) call not found

I find doing it this way to be easier to read and understand than a large list of calls passed into a single method.

If you do care about order or you expect multiple identical calls, assert_has_calls might be more appropriate.

Edit

Since I posted this answer, I've rethought my approach to testing in general. I think it's worth mentioning that if your test is getting this complicated, you may be testing inappropriately or have a design problem. Mocks are designed for testing inter-object communication in an object oriented design. If your design is not objected oriented (as in more procedural or functional), the mock may be totally inappropriate. You may also have too much going on inside the method, or you might be testing internal details that are best left unmocked. I developed the strategy mentioned in this method when my code was not very object oriented, and I believe I was also testing internal details that would have been best left unmocked.

You can use the Mock.call_args_list attribute to compare parameters to previous method calls. That in conjunction with Mock.call_count attribute should give you full control.