[Q] TDD example for client/server development?

-----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-----

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 <[hidden email]> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for your help, and...

Diego Fernandez wrote:
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-----

On 12/3/06, Sungjin Chun <[hidden email]> 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" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Sunday, December 03, 2006 6:20 AM
Subject: Re: [Q] TDD example for client/server development?

Hi Sungjin,

Network programs benefit from TDD as much as any other program.
"MaArmoredCode" is an extension to the SUnit testing that assists with
automating the testing of network programs by conducting the test
through remote-perform calls to other Squeak images, instructing them
to exercise their own network code.  You can even simulate server or
network failures to exercise your error-handling, and then resume the
network test.

You have to define the network players and choose your own ports and
the test-play ports up front.  But once your TestCase subclass is set
up, the suite of multiple images is all launched with one-click,
courtesy of OSProcess.

  http://minnow.cc.gatech.edu/squeak/2659