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<solip...@pitrou.net> wrote:
On Sat, 18 Dec 2010 20:23:49 -0800
Guido van Rossum<gu...@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@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
