[Python-Dev] r87389 - in python/branches/py3k: Doc/library/unittest.rst Lib/unittest/case.py Misc/NEWS

[Michael Foord]

On 19/12/2010 19:55, Raymond Hettinger wrote:
> On Dec 19, 2010, at 10:41 AM, Guido van Rossum wrote:
>
>> On Sun, Dec 19, 2010 at 5:13 AM, Antoine Pitrou<solipsis at pitrou.net>  wrote:
>>> On Sat, 18 Dec 2010 20:23:49 -0800
>>> Guido van Rossum<guido at python.org>  wrote:
>>>> I may be unique, but I fear there is no great answer. On the one hand
>>>> I almost always code it as e.g. assertEqual(actual, expected), which
>>>> matches my preference for e.g. "if x == 5:" rather than "if 5 == x:".
>>>> On the other hand in those assert* functions that show a nice diff of
>>>> two lists, when reading such a diff my expectation is that "old, new"
>>>> corresponds to "expected, actual". Which then freaks me out until I
>>>> realize that I coded it as "actual, expected"... And yet "expected,
>>>> actual" still looks weird to me. :-(
>>> This could be nicely resolved by renaming the arguments "a" and "b",
>>> and having the diff display "a, b". It's quite natural (both the diff
>>> ordering and the arguments ordering), and they are consistent with each
>>> other.
>> So 'a' stands for 'after' and 'b' for 'before', right? :-)
> If you go down the a / b path instead of actual/expected,
> the diffs are straight-forward but some of the other
> output styles needed to be changed also (replace the
> messages for "unexpected" and "missing" elements to
> "things in a but not in b" and "things in b but not in a".
>
>

Ah man, we've *nearly* finished bikeshedding about the names of unittest 
assert methods so its time to move onto the names and order of the 
arguments. Really?

I wouldn't use a/b but first/second [1] as they have a more obvious 
meaning.

However, I'm reluctant to move away from the actual/expected 
terminology. It's standard terminology for testing (used by all the 
other unit testing frameworks I looked at phpunit, JUnit and NUnit), but 
more importantly it is a useful way to think about testing - and one 
used by most devs I've worked with.

You fetch an 'actual' result by calling your code and compare it against 
a pre-computed 'expected' result. Hopefully the two are the same. 
Talking about your actual value and your expected value is a natural way 
to talk in testing, so it's a useful concept.

Once you use the 'actual' and 'expected' terminology you have a natural 
order for displaying failure message results: if an element is present 
in your actual but not in your expected then it is extra. If an element 
is in your expected but not in your actual then it is missing. 
Straightforward. (Of course it maybe that your actual is correct and it 
is your expected result needs correcting, that doesn't affect how 
failure messages should be presented though.)

The only thing left to decide is then the order - (actual, expected) or 
(expected, actual). Raymond, myself, Guido and Ezio have all expressed a 
preference for (actual, expected). I like this comment from Raymond on 
the relevant issue [2]:

     I also tend to use actual/expected and find the reverse to be a 
form Yoda-speak, "assert 5 == x", "perhaps misread the prophecy was", etc.

As the current ordering used within unittest is (actual, expected), to 
reverse it would be dumb (why should everyone using the current ordering 
reformat all their tests for the new order?).

So, -1 on dropping actual and expected. They're standard and useful 
terminology / concepts for testing.

If we do move to a more "agnostic" wording in the failure messages 
(whilst keeping actual / expected as argument names and in the 
documentation perhaps?) then I prefer first / second to a / b.

All the best,

Michael Foord

[1] Interestingly unittest did use (first, second) for assert argument 
names back in 2.1 when it was added: 
http://svn.python.org/view/python/branches/release21-maint/Lib/unittest.py?revision=24536&view=markup 

[2] http://bugs.python.org/issue10573
> Raymond
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk


-- 

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessinghttp://www.sqlite.org/different.html