[Twisted-Python] Removing _wait from Trial

Jonathan Lange jml at mumak.net
Sun Oct 1 03:58:50 MDT 2006


On 9/25/06, glyph at divmod.com <glyph at divmod.com> wrote:
> On Sun, 24 Sep 2006 17:26:10 +1000, Jonathan Lange <jml at mumak.net> wrote:
> >Unfortunately, some of Trial's cleanup code spins the reactor (see
> >t.trial.util._Janitor.do_cleanPending). This has to go.
>
> You are saying this part of the plan will happen post-2.5, I assume?
>

At the least, post #2091. The first wave is "deal with dirty reactor
failing the suite", the second wave is "drastically increase standards
of cleanliness".

This gets taken up below.


> >2. Tighten test cleanup errors. (Twisted 2.5)
> >
> >#2091 (ready for review) fulfils a long-standing promise. The "reactor
> >unclean" warnings have been turned into errors.
>
> I would really like it to be possible to turn these errors into warnings by passing a command-line flag, mainly for the migration path between 2.4 and 2.5.

As you have wished, so have I done.


> Twisted's buildslaves should _NOT_ use this flag, nor should it still be present in 2.6.  I am suggesting it _ONLY_ as a migration tool.

Good. I wasn't looking forward to fighting you to the death: my mech
is in dry-dock.


> >That means we will have to either:
> >a) surprise our users with new errors in their tests
> >b) find some way to introduce this gradually.
>
> I think this might be another use-case for a flag.  Really, developers should be alerted
> to these changes as soon as possible (warnings are too easily ignored), but have a way
> to give themselves a little leeway to fix the problems before the next release.

The --unclean-warnings flag will take care of this.


> >Currently TestCase.run() is a blocking call. I wish it could remain a
> >blocking call, but it can't.
>
> Why do you say you wish it could?  Isn't the whole point here to make it not be a blocking call?

If the reactors were restartable, it could remain a blocking call
without sucking. As it is, I can't have both "blocking" and "not
sucking". So I'm sacrificing the former to get closer to the latter.


> >4. Deprecate TestSuite.run and TestCase.run. (Twisted 2.6)
>
> In what sense are these APIs "public"?  Are there really people calling them outside of the 'trial' tool?

Some people use Trial tests with other tools. Similarly, overriding
run() is the place to start if you want to extend TestCase
functionality.


> >[1] Incidentally, all of this would be superfluous if reactors were
> >restartable.
>
> A clean restart() API would be a possible way of fixing some things, but I think you
> are underestimating how much code would break with a clean restart() method, too.
> For example: the threadpool would be stopped after each test.  Would that make any
> existing Twisted tests fail?  I don't know, but operating under your (probably correct)
> pessimistic assumption that any change to the test framework's interaction with the
> reactor will break some things, I'd have to say yes.

Yes, they would fail. We currently kill the threadpool after every
test *class*, not test case, because some people put certain things in
setUpClass once.


 > Then there is the issue that Bob recently brought up, which is that
in a 'normal' Twisted
> application the reactor is only started once, and so it's not really a representative test to
> constantly be pausing and resuming it.  If we implement a restartable reactor it would
> probably be a good torture-test though.

Lots of unit test tropes aren't representative of real applications.
"Normal" applications don't establish a connection, do one thing, then
disconnect.


Thanks for replying!
jml




More information about the Twisted-Python mailing list