launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Mon, Nov 8, 2010 at 8:38 PM, Michael Hudson
<michael.hudson@xxxxxxxxxxxxx> wrote:
> On Mon, 8 Nov 2010 13:51:26 +0000, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
>> On Mon, Oct 18, 2010 at 5:49 AM, Robert Collins
>> <robertc@xxxxxxxxxxxxxxxxx> wrote:
>> > On Mon, Oct 18, 2010 at 5:20 PM, Tim Penhey <tim.penhey@xxxxxxxxxxxxx> wrote:
>> >> On Mon, 18 Oct 2010 17:07:53 Robert Collins wrote:
>> >>> Wondering if anyone has ideas about this - the branch is trivial -
>> >>> grab a new testtools, use it. Drop things that are now in testtools
>> >>> core.
>> >>>
>> >>> And yet, it fails.
>> >>
>> >> And if you look at the failures, they are in testtools matchers.
>> >
>> > yes, but I don't see /why/ they'd trigger this.
>>
>> Did you ever get to the bottom of this? Inquiring minds want to know.
>
> Yes, it was that a new version of testtools ended up comparing things
> the other way around in assertEquals, and we had some broken tests that
> compared storm expressions and dates (UTC_NOW == anything is true,
> anything == UTC_NOW is not, at least for most values of anything).
>
> I'm pretty sure the fixes to the tests landed.
>

Really, I can't see it.

I landed a "fix" to the tests before I got your email, but all it did
was change the order of the arguments to assertEqual, which makes the
tests kind of pointless.

Now I'm trying to fix the assertions but am somewhat stumped.

More broadly, what's the good of UTC_NOW if it has a broken equality
implementation?

jml