On 11/26/2014 09:28 AM, Nicolas Trangez wrote:
On Wed, 2014-11-26 at 08:54 -0500, Jay Pipes wrote:
On 11/26/2014 06:20 AM, Nicolas Trangez wrote:
On Mon, 2014-11-24 at 13:19 -0500, Jay Pipes wrote:
I think pointing out that the default failure
message for testtools.TestCase.assertEqual() uses the terms
(expected) and "actual" is a reason why reviewers *should* ask patch
submitters to use (expected, actual) ordering.

Is there any reason for this specific ordering? Not sure about others,
but I tend to write equality comparisons like this

      if var == 1:

instead of

      if 1 == var:

(although I've seen the latter in C code before).

This gives rise to

      assert var == 1

or, moving into `unittest` domain

      assertEqual(var, 1)

reading it as 'Assert `var` equals 1', which makes me wonder why the
`assertEqual` API is defined the other way around (unlike how I'd write
any other equality check).

It's not about an equality condition.

It's about the message that is produced by
testtools.TestCase.assertEqual(), and the helpfulness of that message
when the order of the arguments is reversed.

I'm aware of that. I was just wondering whether there's a particular
reason the ordering (and as a result of that the error message) was
chosen as it is.

I'd rather design the API as `assertEqual(value, expected)`, and let the
message indeed say 'Expected ..., but got ...' (and using the argument
values accordingly).

I think you'd have the same problem, no? People would still need to get the order of the arguments "correct".


OpenStack-dev mailing list

Reply via email to