launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #09193
Re: testtools and lingering DelayedCalls
On Mon, Apr 2, 2012 at 3:20 AM, Benji York <benji.york@xxxxxxxxxxxxx> wrote:
> As part of the yellow suqad's test parallelization work I am tracking
> down a test ordering bug (963463). The problem is that some tests leave
> unexecuted DelayedCalls in the reactor which testtools reports as a test
> error.
>
> Normally that would be a good thing, but not all the offending tests use
> testtools so we have a situation where some tests leave the reactor in a
> dirty state (which is not reported because those tests are not using
> testtools) and a later test (which does use testtools) generates an
> error (because of the already dirty reactor).
>
> I am going to try to try to find a way to identify all of the offending
> tests and clean them up, but I doubt I can find and fix them all within
> a reasonable time box.
>
I'm pretty sure it's only the distribution_mirrorprober tests. I
changed all of the other tests to use testtools Twisted support. I
didn't change those because they are extremely unusual, and I couldn't
make much sense of them. Although this knowledge is many months out of
date.
testtools also has a debugging option that you can use to identify
these tests more readily. Or, you could just set DelayedCall.debug =
True and run through the tests.
> I would like to propose changing testtools such that if the reactor is
> dirty at the start of a test a warning is issued and the reactor is
> cleared out. That way we only generate errors when we can pinpoint the
> culprit test.
I think I'd be OK with something along those lines. Note that
testtools itself (I think) cleans out the reactor as it's generating
those warnings, so you'll only see such behaviour when you are mixing
it with other Twisted testing approaches.
jml
Follow ups
References