On Mon, Nov 8, 2010 at 8:38 PM, Michael Hudson <[email protected]> wrote: > On Mon, 8 Nov 2010 13:51:26 +0000, Jonathan Lange <[email protected]> wrote: >> On Mon, Oct 18, 2010 at 5:49 AM, Robert Collins >> <[email protected]> wrote: >> > On Mon, Oct 18, 2010 at 5:20 PM, Tim Penhey <[email protected]> >> > 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
