[Twisted-Python] Running twisted.trial unittests using nose

glyph at divmod.com glyph at divmod.com
Mon Aug 6 07:20:45 MDT 2007


On 12:17 pm, miles.chris at gmail.com wrote:
>I'm simply curious as to whether it is safe for me to rely on a test 
>runner other than "trial" to run the tests?  I assume any magic 
>(knowledge of deferreds) is within the  twisted.trial.unittest.TestCase 
>class and the "trial" command is  simply another tool to discover and 
>pretty print the results.  From  what I've seen, both "nosetests" and 
>"trial" will produce the same  report (although "trial" looks nicer 
>:-).  Or perhaps this wouldn't  be the case if I needed to interact 
>with the reactor?

There is an implicit, undocumented goal that tests written for trial 
should remain usable with other test runners.  Recently, I filed a 
ticket because not even *I* know which test runners or how this is 
supposed to work.  You can follow the discussion / resolution here:

    http://twistedmatrix.com/trac/ticket/2739

Personally I'd never use nose because, as you say, trial looks nicer :), 
so I can only guess what's going wrong.

The potential problem (currently) with using Twisted's TestCase class 
together with other runners is that the tests do something that no other 
Twisted application does, and which is not _really_ supported by the 
framework: re-start the reactor repeatedly.

Eventually, 'trial' itself will not do this, and will behave as a 
"normal" Twisted application.  'trial' will, as stated by the ticket I 
just linked to, still support other test runners by having a 'run' 
method that starts and shuts down the reactor, but it won't be used 
internally.  The main reason to do this is that there are various tools 
which would be nice to use Twisted functionality in-process with the 
tests for reporting results.  Doing that will probably remain a trial- 
exclusive feature, because other test runners will necessarily need to 
completely shut down the reactor at the end of each test.




More information about the Twisted-Python mailing list