best practice to test socket server?

Question

I'm developing a socket server game using java. I want to test if server works properly (how it handles received messages, process and response in right way...) without using game client(heavy and not completed). Messages from client maybe raw binary and encrypted.

Is there a framework, or testing tool for this case?

Answer 1

If you want to do it by hand, I would suggest telnet or, if you're using Linux, you can use netcat command nc.

If you want something that can be automated, e.g. a unit test, and you're familiar with Python, I would recommend using Twisted: Twisted Examples

Hope this helps

Answer 2

There are several steps that I take when testing client server systems and mostly I tend to use "normal" unit testing frameworks for this kind of thing, though it only works if you've already designed your code to be unit testable. I also often write a specific stress test client for the server; this can create many thousands of concurrent connections and perform operations on the server and check that it gets the expected results.

For initial server testing you want to have a set of unit tests in place for the key server components; message parsing, etc, and you want to have isolated these components from the code that actually deals with the network (so that you can test it all in a unit test). Push data into the server's message parser and make sure that it parses correctly, and calls the right things, etc.

You can then use your normal unit testing framework to create an instance of your server object (with suitable mocks) which listens on the network and then create a simple client which you instantiate within the unit test and which tests aspects of the server. Often you'll find that there are only a small number of things you actually MUST test like this. Normally connection establishment and termination issues which you want to test with the network as well as independently of it (after all, you can call the connection establishment and disconnection code on your server class from a normal unit test anyway).

Finally you need a custom client which understands your protocol and can put pressure on the server with 1000s of clients - this is the best way to drive out performance and threading issues.

I tend to work on all of these things from the very start; see this blog post for more details.