Open Stack

On Wed, Nov 26, 2014 at 08:54:35AM -0500, Jay Pipes wrote:
> 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.
> 
> This is especially true with large dict comparisons. If you get a message
> like:
> 
>  reference: <large_dict>
>  actual: <large_dict>
> 
> And the arguments are reversed, then you end up wasting time looking in the
> test code instead of the real code for the thing that is different.
> 
> Anyway, like I said, it's not something that we can write a simple hacking
> check for, and therefore, it's not something that should have much time
> spent on. But I do recommend that reviewers bring it up, especially if the
> patch author has been inconsistent in their usage of (expected, actual) in
> multiple assertEqual() calls in their patch.

I think Nicolas's question was what made testtools choose this ordering. As far
as I know, the python docs for unittest uses the opposite ordering. I think
most people can see that the error messages involving 'reference' and 'actual'
are useful, but maybe not the fact that in order to achieve them using
testtools, you need to go against the norm for other testing frameworks.

(fwiw, I'm an advocate for using the ordering with the best error messages)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141126/1a9536b6/attachment.pgp>