-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm finding example code/doc for simple echo server/client development using TDD. I've found many examples for TDD, however, they are mostly for simple single application only.
Can anyone help me?
Thank you in advance.
I have done a lot of TDD for client/server (web services, http, GemStone, LDAP) and my experience is this:
- First of all focus in what behavior you are testing: are you testing all the communication framework or are you testing the client (or server) behavior? This is important because in most cases the communication framework is already done, so you don't need to test it again, ie testing (directly or indirectly) that the Socket object works is non sense, unless you are writing the behavior for the Socket object.
- Create a unit test for the client side, "mocking" the server side. Maybe you may need to re-think your design to be more decoupled from transport mechanism or specific communication frameworks, but I think that is a good side effect of TDD :) - Do the same for the server.
So now, you have "simple" tests for the client and the server :)
Then you can make a more complex test that initializes the server on #setUp, and them does a shutdown in #tearDown. Another option is to start up the server in the #setUp of a TestResource, so the server could remain running during the execution of all the tests.
Note that kind of tests is not in the "spirit" of unit tests, because they test a lot more (you are testing the client, the server, the communication protocol and the communication transport in one test), an usually requires external resources to run... But they are very useful too! So you can do them using the SUnit framework, but running them apart from the rest of the unit tests. (this is just a development practice... I usually have a TestSuite of "Unit Tests" and a TestSuite of "Integration Tests" or "User Story Tests")
For your question about the "echo" server test, you could do something like this (this is a really silly example...):
EchoServerIntegrationTest>>#setUp server := EchoServer configuredBy: self serverConfiguration. server startUp.
EchoServerIntegrationTest>>#testCommunicationResponse | client | "Note that EchoClient it's a proxy of EchoServer, so maybe both have protocol, like #echo:... maybe you can call them Parrot and ParrotProxy :P"
client := EchoClient connectedTo: self serverLocation. self assert: (client echo: 'hello') = 'hello'.
"There is a lot of details that you need to think in a more complex client/sever app, for example maybe you have to reify the concept of 'session' "
EchoServerIntegrationTest>>#tearDown (server isNil or: [server notStarted ]) ifTrue: [^self ]. server shutDown
I hope it helps, Diego,-
On 12/1/06, Sungjin Chun chunsj@embian.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm finding example code/doc for simple echo server/client development using TDD. I've found many examples for TDD, however, they are mostly for simple single application only.
Can anyone help me?
Thank you in advance. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFcORKQqspS1+XJHgRAsX+AJ47lv+WU/WogDjLRiRERR9zKP0aYgCeIrfY ZhZl7bSGRlD14+N+xuoO+tA= =Tt1X -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thanks for your help, and...
Diego Fernandez wrote:
I have done a lot of TDD for client/server (web services, http, GemStone, LDAP) and my experience is this:
- First of all focus in what behavior you are testing: are you testing
all the communication framework or are you testing the client (or server) behavior? This is important because in most cases the communication framework is already done, so you don't need to test it again, ie testing (directly or indirectly) that the Socket object works is non sense, unless you are writing the behavior for the Socket object.
I want to create/test communication framework - actually I use this example for educating TDD for client/server development. Most guys in our class do think TDD is inappropriate for client/server development, even for simple echo server/client case. They say how can you make your step small enough to TDD when you cannot test communication.
So I have to write the behavior of the Socket object.
Thanks again.
On 12/3/06, Sungjin Chun chunsj@embian.com wrote:
So I have to write the behavior of the Socket object.
Well unless that you are writing an OS from scratch... you already have a C API for sockets :) The first step could be a test for the "binding" with the external socket API (like loading the socket library, initialization, open, close without errors).
If you are writing an OS using TDD --maybe SqueakNOS :)--, I think that you could start with a "mock" network card that writes the input/output to a Stream.
You could also start the initial test with an already implemented echo server, so you don't have to write a server to test the client Socket. For example: EchoServerTestResource>>#setUp osServerProcess := self startProcess: 'echoDaemon'. EchoServerTestResource>>#tearDown osServerProcess kill
I did that to test LDAP useractions for GemStone (useractions is the term used in GemStone for C libraries that could be used from Smalltalk). So even if the server takes a few seconds to start (like OpenLDAP), the #setUp method of the TestResource is called once until someone sends the #reset message.
I think that if the server is small and could be easily installed by each developer in the team, using a real server is more easy than using a lot of mock objects.
Regards, Diego
I do all my TDD stuff (working on a SIP+RTP stack) the way Diego does.
The word "communication framework" is not very tightly defined: a SIP stack is a pretty complicated communication framework for people to use, layered on top of the OS's communication framework. Which communication framework do you mean? A socket implementation? Or something that sits on top of Socket/SocketStream type classes?
Either way, what worked really well for me was completely separating the workings of the SIP protocol stack from the socket layer. In Squeak I guess that would be something like MockSocketStream.
So I'd write a test that showed, say, that my client classes serialise a message correctly to the socket. Then I'd write a test showing that my server classes can parse a message correctly. Then I'd write a test showing that what the client serialises is what the server can parse :). Then I'd add the next series of tests.
Finally, I'd write tests removing the mocked-out sockets, and run actual clients and servers on actual sockets and communicate via the underlying network. That's really an end-to-end test (I forget what the literature calls these tests), not a unit test.
But still, Diego's got it in a nutshell: test the client and server separately, and then test them together. (And don't forget about interoperability testing, if implementing a standard!)
frank
----- Original Message ----- From: "Sungjin Chun" chunsj@embian.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Sunday, December 03, 2006 6:20 AM Subject: Re: [Q] TDD example for client/server development?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thanks for your help, and...
Diego Fernandez wrote:
I have done a lot of TDD for client/server (web services, http, GemStone, LDAP) and my experience is this:
- First of all focus in what behavior you are testing: are you testing
all the communication framework or are you testing the client (or server) behavior? This is important because in most cases the communication framework is already done, so you don't need to test it again, ie testing (directly or indirectly) that the Socket object works is non sense, unless you are writing the behavior for the Socket object.
I want to create/test communication framework - actually I use this example for educating TDD for client/server development. Most guys in our class do think TDD is inappropriate for client/server development, even for simple echo server/client case. They say how can you make your step small enough to TDD when you cannot test communication.
So I have to write the behavior of the Socket object.
Thanks again. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFclCUQqspS1+XJHgRAoOzAJ4zdw9I5hZqpijUe86Z9c+5j1WwWwCeL0CX NdzByoMuUo8sJwJE6/qxSVg= =wGyE -----END PGP SIGNATURE-----
squeak-dev@lists.squeakfoundation.org
-
Diego Fernandez -
Frank Shearar -
Sungjin Chun