[Twisted-Python] Refactoring of trial - call for feature requests and suggestions

[Brian Warner]

> What's the point of this, exactly? How would you assert things about the
> result of the Deferred? I've been using the functions in twisted.trial.util
> for a while to deal with Deferreds in my tests, and it seems rather nice.

I assume the Deferred that comes back from the test case would merely be
expected to fire the callback successfully, and the value passed to that
callback would be ignored. Any result-checking would be done in chained
callbacks that fired beforehand.

The Deferred would just be to tell trial that it should spin the reactor
until the test completes. Oh, a feature request: please spin the reactor
gently.. use iterate(0.01) instead of iterate(), to avoid spamming the CPU on
tests that are gated by reactor.callLater. Also there should be a built-in
timeout, or an easy way to set one (with a default timeout imposed if the
method returns a Deferred without first setting a timeout).


Re: reactor cleaning, I think it's important that the reactor be in exactly
the same state before and after the test, which is more complicated than the
current checks we have in place (it should include resetting the state of
various "one-time" initializations, like threads, since we've had a few
failed-to-initialize-something bugs that were masked by earlier tests
performing the missing initialization). For this, I think we need a
reactor.clean or .reset method.

I'm undecided about whether tests should be expected to clean up after
themselves (i.e. if a test is flunked when reactor.reset has something to do
afterwards). It may be easier all around to establish the convention that the
reactor will be cleaned by trial so that the test case doesn't have to.

 -Brian