[Twisted-Python] Testing Twisted code without trial

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Tue Jan 22 15:03:29 EST 2013

On 09:29 am, adi at roiban.ro wrote:
>On 22 January 2013 02:21,  <exarkun at twistedmatrix.com> wrote:
>>On 20 Jan, 02:35 pm, adi at roiban.ro wrote:
>>>I start my pet project using Python Nose as test runner. At the 
>>>Twisted not used at all.
>>>Later I discovered Twisted and start using it... but testing Twisted
>>>requires trial.
>>>I resist migrating to Trial and ended up with a custom code for
>>>running Twisted tests together with Nose:
>>>I though I can share this code on the list, in case there is someone
>>>else wrestling with deferres testing outside of Trial.
>>>Any feedback or comments is much appreciated.
>>The implementation is somewhat saddening in its use of Twisted 
>>(which makes it fragile and subject to easy breakage by new Twisted
>>releases) and limited platform support (it won't work on Windows,
>>You may also find problems with direct use of `reactor.iterate`, since
>>use of this API is highly discouraged due to re-entrancy issues and 
>>implementation is not all that well tested by Twisted's own test 
>>If it works for you, great, but I would hesitate to recommend it to 
>>projects as a testing tool.  As Itamar suggests, nose should be able 
>>run xUnit-style tests.
>Thanks for your feedback.
>The new methods successResultOf and failureResultOf looks good, but I
>think they only work with deferred that already have a result.
>I am aware that the whole thing is fragile... and I am aware of the
>consequences of using internal non-public methods.
>I checked the code from twisted.trial.unittest.TestCase but I could
>not spot how it waits for deferreds execution.
>What part of twisted.trial.unittest.TestCase executes and waits for
>the deferred?
>Can I use that code to implement something similar to successResultOf
>and failureResultOf but which also executes the deferred?

Hi Adi,

trial does what it does by touching a lot of internal stuff as well. 
This is still bad, but at least it's our fault if it ever breaks instead 
of yours.  There's also a long term plan (or "plan" may be putting it 
too strongly, perhaps I should say "hope") that this part of trial will 
change to only use public interfaces.  This will probably require 
reactors actually implementing restartability, or it will require 
changing the trial feature slightly (eg, so it starts a reactor, runs 
all tests, then stops the reactor - if it did this, I'm sure you can 
imagine how "waiting" for a Deferred would just be adding a callback to 
the right place, as in any other Twisted-based application).

Are you interested in helping out with making reactors restartable? :)
>This code also works on Windows and on other Unix systems (OSX, 

Okay.  I expected otherwise when I saw `_UnixWaker` in the 
implementation, but reading more carefully I now see that the code 
doesn't ever try to instantiate or use one of these, it just needs it 
for type checking.  My mistake!


More information about the Twisted-Python mailing list