On Tue, Dec 21, 2010 at 1:31 AM, Antoine Pitrou firstname.lastname@example.org wrote:
Diffing is completely an implementation detail of how the failure messages are generated. The important thing is that failure messages make sense with respect to actual result and expected result.
Which, again, they don't. Let's see:
self.assertEqual(actual, expected) AssertionError: 'a\nb\nc\ne\n' != 'a\nb\nc\nd\n' a b c
The diff shows "expected - actual", but it would be logical (in your own logic) to display "actual - expected". The whole issue disappears if you drop this idea of naming the arguments "actual" and "expected".
To make this a bit clearer...
... def demo(self): ... self.assertEqual("actual", "expected") ...
Traceback (most recent call last): <snip TB details> AssertionError: 'actual' != 'expected' - actual + expected
For the actual/expected terminology the diff is the wrong way around (as of 3.2b1, anyway).
My own +1 goes to keeping the actual/expected terminology (and ordering) and adjusting the diffs accordingly (with a header noting that the diff is old=expected, new=actual).
assertRaises() *is* an exception to the general actual/expected pattern, but that asymmetry is forced by the ability to pass arbitrary positional arguments to the function being tested (which later proved useful for the context manager form as well).