New submission from exarkun <[email protected]>:
`loopbackAsync` connects to protocol instances to each other, providing two in-memory transports which send bytes written to them by one protocol object to the `dataReceived` method of the other protocol (much like an actual transport would).
The currently implemented behavior is a little unrealistic. When the data delivery phase comes, each string written to one transport is delivered to the other protocol separately. So if a protocol writes "foo", then "bar", then "baz" to its transport, the other protocol will receive "foo" in one call to `dataReceived`, "bar" in a second, and finally "baz" in a third. A real transport would probably clump these together sometimes, or split them up, or clump them and then split them along different boundaries differently.
Protocols are supposed to deal with this kind of clumping and splitting, and while the behavior implemented now isn't ''wrong'' - but it might trick developers into thinking that their code works, when really it only works for the exact chunks their tests produce.
It would be pretty neat to have a thing which could generate several tests automatically, based on a single test method implementation, which exercised lots of different chunking behaviors.
However, for a start, it would be nice if the chunking behavior were a parameter to loopbackAsync, so that tests that ''know'' they want to exercise a different code path can.
In particular, I want this for #593 so that I can exercise the case of multiple SSL messages
being delivered in a single call to `dataReceived`.
----------
Type : enhancement
Component: core
Keywords : tests
Priority : high
Nosy :
----------
http://twistedmatrix.com/trac/ticket/3820
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.