On July 22, 2014 at 7:54:17 AM, Tobias Oberstein ([email protected]) 
wrote:
Hi,  

I am maintaining AutobahnPython, a library that supports Twisted and  
asyncio/Trollius in one codebase.  

Now, ideally, I'd like to write unit tests that work across all variants  
- while avoiding code dups.  

In Twisted, there is Trial, which provides an extended version of  
unittest.TestCase with this feature:  

"""  
The main unique feature of this testing class is the ability to return a  
​Deferred from a test-case method. A test method which returns a  
Deferred will not complete until that Deferred has fired; the reactor  
will be automatically set up and run for you, along with a timeout to  
make sure that tests don't run forever. If the Deferred fires  
successfully, the test passes. If it fires with an error, the test  
fails. This makes it possible to easily unit-test asynchronous  
event-driven code, or to use Twisted APIs that return Deferreds in order  
to write automated functional tests that communicate with a live running  
service.  
"""  
http://twistedmatrix.com/trac/wiki/TwistedTrial  

I am wondering if there are any plans to add something similar to  
asyncio/Trollius. That is:  

a) an extended TestCase base class  
b) a test driver (analog of "trial" command)  



I strongly recommend you reconsider doing this.

The Twisted core developers have, for several years now, mostly eschewed the 
usage of returning Deferreds from test cases. Instead, tests are written by 
explicitly controlling all events explicitly, with careful use of test doubles 
to replace certain features of the event loop. There’s also a class in Trial, 
“SynchronousTestCase”, which offers utilities such as 
synchronousResultOf(Deferred) -> result and synchronousFailureOf(Deferred) -> 
result, which both assume the Deferred has fired synchronously (which your test 
case can ensure). The testing philosophy in Twisted is: if you need the global 
event loop to really truly run, it’s not a unit test.

Trial’s return-a-Deferred feature is still useful in certain integration test 
situations, where you really want to talk to the Internet or interact with the 
user in your set of test suites, but for unit tests, it’s possible to exercise 
all code paths before the test method returns.



-- 
Christopher Armstrong
http://twitter.com/radix
http://wordeology.com/

Reply via email to