I'm not sure if we've written this down anywhere official-looking, but if you're writing new tests in Twisted today, there is no reason that they should ever return a Deferred. Returning Deferreds from tests in Trial is useful _only_ for writing integration tests that rely on external services which cannot be reasonably implemented or faked within Twisted itself. In some applications, this is an unfortunate fact of life, which is why Trial provides the feature and will continue to provide it. For example, writing unit tests for a database-backed application which depends intimately upon stored procedures would require altogether too much mocking and it's useful to be able to simply call out to the real database within tests. However, this is assuming that you can run your database locally in isolation as part of your test suite, and there is absolutely no non-determinism present in the application's communications with its database. However, there is nothing like this within Twisted itself. In extreme cases where you actually need to test real platform interactions, you can instantiate a reactor for your test and iterate it as the ReactorBuilder tests do, but in any case where you're testing a client/server interaction, parsing bytes, etc, you can use twisted.test.proto_helpers or twisted.test.iosim. In the branch I'm working on right now I'm moving some more general testing utilities from individual tests over to twisted.test.ssl_helpers as well, so it should be easy to test any TLS interactions you might have as well. (Note, these are for testing within Twisted only right now, at some point we need to clean up all the generally-useful things in twisted.test, including proto_helpers, put them in a module outside of *.test...) To sum up: there is absolutely no reason whatsoever to ever use loopbackAsync, please don't ever use it in a new test. Thanks, -glyph