>>> m=mock.Mock()
>>> m.some_method('foo', 'bar')
<Mock name='mock.some_method()' id='140353787504656'>
>>> m.some_method.assert_called_once_with('foo', 'bar')
>>> m.some_method.assert_called_once_with('foo', 'baz')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/mock.py", line 846, in assert_called_once_with
    return self.assert_called_with(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/mock.py", line 835, in assert_called_with
    raise AssertionError(msg)
AssertionError: Expected call: some_method('foo', 'baz')   #####
Actual call: some_method('foo', 'bar')                     #####
>>>

What specifically are you saying is in the wrong order?

IMHO, the trace should be:

AssertionError: Expected call: some_method('foo', 'bar')   
Actual call: some_method('foo', 'baz')                    

instead of below:

AssertionError: Expected call: some_method('foo', 'baz')   
Actual call: some_method('foo', 'bar')

But the actual call that you made in your example was some_method('foo', 'bar').

Given that we conventionally write unittest assertions with the actual result first and the expected result second (assertEqual(actual, expected), it might be less confusing if the message was:

  AssertionError: Actual call: some_method('foo', 'bar')
  Expected call: some_method('foo', 'baz')

But since the actual call does appear in the assert call that generates the assertionError, it is not obvious that this would actually be a better order.

As David points out - in your example the "actual call" made is m.some_method('foo', 'bar'). Your assertion (the expectation) is  m.some_method.assert_called_once_with('foo', 'baz').

So the traceback is correct. I don't think the ordering of expected/actual in the output matters.

Okay, I can see your point now. Thanks for the clarification.