On Oct 25, 2012, at 2:22 PM, exar...@twistedmatrix.com wrote:
> On 09:18 am, lacrima.ma...@gmail.com wrote:
>> Hi!
>>
>> I am learning to develop TDD way. I want to create a server that
>
> Hooray!
Yes, hooray! I wish that everyone did this. Sorry that you've encountered
trouble; I very much hope you will stick with this and help us make the process
for doing TDD on PB (and generally, Twisted) applications much easier.
>> understands PB protocol. Initially I thought it would be a good idea to
>> avoid real network connections in my tests, so I tried to use
>
> Yes, that's definitely what you want to do.
>> `proto_helpers.StringTransport`:
>
> StringTransport is frequently what you want in order to test a protocol
> implementation, so you're on the right track.
>
> Except... actually you're not implementing a protocol. You're *using* a
> protocol implementation that exists already and has its own unit tests.
>
> It would be better if you found a way to test your code without
> involving the PB protocol implementation or StringTransport. However, I
> admit that the tools for doing this with PB are almost non-existent. On
> the other hand, application code written for use with AMP is much more
> amenable to testing.
>
> Just something to think about.
While I agree with everything exarkun has said here, I think we should note
that using StringTransport is basically the state of the art in protocol
testing at this point. It's unfortunate that we don't have anything better,
but you shouldn't feel the need to go scouring the code base for a good example
or a testing utility that you've missed; unless it's immediately obvious to you
how to remove byte-level parsing from the equation, this is just an area that
Twisted needs to work on.
> So far so good. You made a factory, got it to make you a protocol, and
> hooked the protocol up to a StringTransport you made. That's all good
> stuff.
I'm curious, since we rarely get to see the positive impact of documentation,
and only hear about it when it didn't exist - did you discover this testing
style from
http://twistedmatrix.com/documents/current/core/howto/trial.html#auto5 ? :)
> Instead, you should probably use the PB client API (ie, PBClientFactory
> and what comes out of it) to interact with this server. Let the PB
> client implementation figure out what bytes to "send" to your server.
To be clear, you should use PBClientFactory in the same way you've been these
other abstractions: create it with a string transport, don't hook it up to any
sockets or anything.
There are three (count them, three!) classes called "IOPump" in various Twisted
test-support modules. Please note that unlike the stuff in proto_helpers these
are not supported and will likely go away in a future version of Twisted.
However, they do provide a simple demonstration of how to hook up a client and
server (calling dataReceived() with what transport.write() produced).
If you'd like to help Twisted itself, we could really use a patch that cleans
up all three of those implementations of IOPump, tests them, documents them,
and exposes them in a way that would be beneficial to those writing tests like
yours.
Thanks for doing TDD,
-glyph
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python