[Twisted-Python] Getting rid of "DirtyReactorWarning"

[exarkun at twistedmatrix.com]

On 15 May, 10:26 am, itamar at itamarst.org wrote:
>I have a ticket open for allowing tests that look like this, where each
>run has a new reactor instance:
>
>
>def test_somethingShouldHappen(self, reactor):
>      result = []
>      reactor.listenTCP(...)
>      self.runReactor(reactor)
>      self.assertEqual(result, ["hooray"])
>
>
>Further thought suggests however that this doesn't add much,
>necessarily, over the current "return a Deferred" idiom for most users.
>Experience with ReactorBuilder framework that has similar testing
>mechanism suggests it's far too easy to fail to stop the reactor.
>Moreover, things like coiterate() don't work since they rely on
>pre-imported global reactor, and given the "from twisted.internet 
>import
>reactor" idiom this testing style won't work well for many people's 
>code.
>
>But! ReactorBuilder tests are superior in one way: no
>DirtyReactorWarning. You don't have to wait until all connections are
>closed, which is difficult, or make sure to cancel every timeout. This
>makes test writing simpler.
>
>Perhaps we should get rid of DirtyReactorWarning for regular
>Deferred-returning tests as well, then. We have all the infrastructure
>we need, after all, for canceling scheduled events and disconnecting 
>all
>descriptors. We might want to log when we do so, to help debug things,
>but we already have cleanup code mostly implemented in trial anyway, 
>and
>it seems like DirtyReactorWarning doesn't usually make future tests 
>fail
>anyway since we do run cleanup.
>
>Threaded code might still be a problem, but that's the case for current
>tests now, and even switching to a new style of tests as above would
>only somewhat mitigate the issue.

I think you should talk to jml about his ideas for a new base 
`TestCase`-like class which is better factored with respect to its 
handling of Twisted-related reponsibilities.

I don't think just removing `DirtyReactorWarning` from all the places it 
is currently emitted is a good idea (if only because it is providing 
*us* value, and because new behavior merits new interfaces).

More generally, I don't think ReactorBuilder is the best approach for 
unit testing anything except reactor implementations, just as I don't 
think using a real reactor (with real time, real networking, etc) is the 
best way approach for unit testing application code that uses the 
reactor.

We need to keep improving our test doubles, documenting their usage, and 
porting our own test suite (the application-y parts, at least) to them.

Jean-Paul