← Back to team overview

launchpad-dev team mailing list archive

Re: Stop the line: Test failures in *stable*

 

On Thursday, October 7, 2010, Michael Hudson
<michael.hudson@xxxxxxxxxxxxx> wrote:
> On Thu, 7 Oct 2010 19:33:43 +0100, Graham Binns <graham@xxxxxxxxxxxxx> wrote:
>> On 7 October 2010 19:21, Francis J. Lacoste
>> <francis.lacoste@xxxxxxxxxxxxx> wrote:
>> > And additionnally, spot checks seem to indicate that these tests continue to
>> > run successfully in subsequent builds.
>> >
>> > So:
>> >
>> > a) these tests were not skipped
>> > b) they pass in the buildbot environment
>> >
>> > Another case, where the difference between our dev, production / test
>> > environement is hurting us.
>> >
>>
>> Note that the test that I fixed, which is now in devel, was failing
>> due to an ordering problem and always passed locally; I'm not sure
>> that there's much we can do to avoid those except remind reviewers to
>> be vigilant for potential issues.
>
> Back in the SQLObject days we had a hack that would add "ORDER BY
> random()" to any query that didn't have an ORDER BY already.  Do we
> still have that?  Although in this case it seems we had an ORDER BY,
> just not a sufficienly discriminating one.  Could you add ", random()"
> to any query that does have an ORDER BY?
>

Wouldn't that just break everything that relied on a specific ordering?

> --
>
> Separately, it seems this problem may have been perpetuated by simply
> changing a doctest to match observed output, and not understanding why
> the output had changed.  Let's not do that again? [1]
>

Agreed. In this case, I don't think it was understood just how often
BugTask.date_last_modified gets updated.

> Cheers,
> mwh
>
> [1] Of course, this is harder if the tests are not clear about what they
>     are testing and why.  Most of you heard me rant about this at the
>     epic.

+1

-- 
Graham Binns
http://grahambinns.com



Follow ups

References