#5354 enhancement new
Create a real, tested, in-memory loopback transport that has fine-grained controls and doesn't run the real reactor
|Reported by:||Glyph||Owned by:|
Right now if you want to deliver data between two protocol instances (let's say that you're using an implementation of a protocol to implement an application, rather than testing the implementation of the protocol itself, so you're not concerned with testing individual aspects of the protocol implementation), your options within Twisted are:
twisted.protocols.loopback- this is module is old, and bad because while it might not make use of the real reactor, it does ask your test to return a
Deferred, which therefore might use the real reactor. This is arguably to improve integration testing, but it doesn't really do much good; events fire either in totally deterministic order, or in 99.9% totally deterministic order; it has no facilities for shuffling events around to actually catch edge cases. In a sense it is the worst of both worlds.
twisted.test.test_pb.IOPump- this is private (
proto_helpersis bad enough, let's not make all of
twisted.testpublic) so applications can't use it, plus, it's also somewhat ad-hoc and still difficult to control; there's no facility to deliver data only in one direction, for example.
- write your own new thing that implements a new random subset of
ITransportet. al. This is, hopefully obviously, bad because it just proliferates more test infrastructure to maintain, and more untested fakes to synchronize with the real implementations.
Once this is implemented I think it would also be nice to give
.listenTCP an internal routing table which would establish these types of connections, but maybe that's a bit more contentious and a separate ticket.