On 9/25/06, glyph@divmod.com <glyph@divmod.com> wrote:
On Sun, 24 Sep 2006 17:26:10 +1000, Jonathan Lange <jml@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