The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Test-driven design with IPC

Question: I am learning about TDD. I am wondering how TDD can be used in an IPC situation. For example:

Suppose I have a group of processes talking through UDP and one of them acts as a "router" between all the rest.

My understanding of TDD is I could test methods that are local to each process. I could test that calling send(123) on process A will produce string "ABC" to send. I could also test that calling receive() on process B, given the string "ABC" to receive, will indeed return the string "ABC".

But now, I want to make sure that when I send a message from A to B through the "router" that it arrives. How could I test this a la TDD? Any ideas besides typical IPC mechanisms (write results to shared files/shared memory, and then write code to read from them and assert values, etc.)? Or am I relegated to writing tests at the "router" as well to make sure it will send a message to the intended process?
MoffDub Send private email
Monday, May 05, 2008
Probably you are going to need some kind of central repository of logs, which are then reconciled:

Log has:

A sent message "ABC123XYZ789" to B

Then you need to reconcile that with a log entry:

B received message "ABC123XYZ789" from A

Obviously this is just a sample of what the real log would look like.

So these aren't really unit tests because it requires an entire environment to be functioning, but it allows immediate feedback on changes.

And, of course, there is some extra work involved.
Monday, May 05, 2008
TDD is actually a design practice focused on the class/unit level. What you are describing is more like component level functional testing.

At any rate, you could test the behavior of the components using mock objects. For example, make sure that the router makes the proper calls when a message arrives. This way, you should be able to verify most of the system behavior before you move on to expensive integration testing.
Monday, May 05, 2008
Sounds like you actually want to test the router not the other IPC code (ie the thing that is sending the routed message or the thing that receives the routed message) so why not write a test harness for the router that sends messages into it and ensures that the messages get to the required destination. This COULD mean that you have to write custom "route from" and "route to" processes and have them communicate with each other in a way that doesn't use the router. This may be more work than you'd like, it may or may not be worth doing.

It doesn't really sound like you want TDD as such, unless you havent written your router yet. This is more like functional testing. You could have written the three pieces (sender, router, receiver) independently using TDD practices and now you need to integrate them.
Len Holgate Send private email
Tuesday, May 06, 2008
Thanks all for the replies. Confirmed my understanding that this is not your typical TDD situation and that extra maneuvering is in order.

This sort of setup is actually from a TCP/IP course I took where we wrote a semester-long "simulation" of the internet running on one machine. Now that I'm reading Jimmy Nilsson's Applying Domain-Driven Design and Patterns, which has a section TDD, it got me thinking about how I would've used it on this project.

As I was writing my original post out, the idea came to me to unit-test the "router" as well. I suppose after it passes those tests, if it fails when they are all actually connected together, I'm now into the dangerous waters of an integration bug.

This assumes that you are writing the router or have access to its source. If not, then I guess you're stuck with the log idea. Then again, that might not be a big pain either since I have the logs there anyway for general debugging purposes.
MoffDub Send private email
Tuesday, May 06, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz