How to test drive a networking application with custom protocol?

I'm currently developing two Java networking applications for school projects. One over TCP and the other one over UDP. In both I have to implement simple custom protocol.

Even though I'm trying pretty hard, I can't find a way how to correctly test this kind of apps, or better develop with test first development.

If I have a client and I want real test without stubbing everything out, I have to implement server with simulated behaviour, which in case of simple apps like these is almost the whole project. I understand, that when something big, than writing few lines of Perl script to test it could really help.

Right now I'm developing server and client simultaneously, so that I can at least test by hand, but this doesn't seem like a clean way to develop. The only thing that is helping is t开发者_Python百科unneling the connection through logger, so that I can see all the data that goes through (using TunneliJ plugin for IDEA).

What is the best way to TDD a networking application with custom protocol? Should I just stub everything and be fine with it?

Separate the protocol from the network layer. Testing the logic of the protocol will become easier once you can feed it your own data, without the need to go through the network stack. Even though you are not using Python, I'd suggest to look at the structure of the Twisted framework. It's a nice example of how to unit-test networking applications.

We wound up with the same problem a while ago. We decided it was simpler to put two developers on the task: one to write the server and one to write the client. We started working in the same office so that we could code, test, modify, repeat a little bit more easily.

All in all, I think it was the best solution for us. It gave us the ability to actually test the program in conditions there were not ideal. For instance, our Internet went out a couple of times and our program crashed, so we fixed it. It worked rather well for us, but if you are a sole developer, it may not be the solution for you.

Whatever you do, when writing a custom protocol, I would check out Wireshark for monitoring your network traffic to make sure all of the packets are correct.

In my app I have code such as this

    m_socket.receive(packet);

    doSomething(packet);

I mock up the receive and hence can exercise everything that doSomething() needs to do.

Where does this break down for you? Here you are truly unit testing that your code behaves correctly, you can also mock the socket send, and se expectations for what you think should be sent according to your protocol.

We are of course not actually testing that the other end of the protocol is happy. That's integration testing. I always hanker after getting to IT as soon as possible. It's when you interact with the "other end" that you find the interesting stuff.

You are in the luck position of being in control of both ends, in that position I would probably spend some time instrument to create suitable, controllable test harnesses.