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
snip
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
Are you referring to Twisted code or to _user_ code (on top of Twisted)?
I am asking since
http://twistedmatrix.com/documents/current/core/howto/trial.html#testing-a-protocol
seems to encourage writing unit tests for user code with test methods
returning deferreds. In fact, this document is what I used for guidance.
Is it outdated?
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.
Is there any document on this best practice - applied to testing user
code, including protocols?
And: I'm sure Twisted developer's will have reasons for frowning upon
tests returning deferreds, but could you recap shortly why?
Thanks for your hints,
/Tobias
--
Christopher Armstrong
http://twitter.com/radix
http://wordeology.com/
