Testing network code

Sure. Also, you might want to look into running virtual machines on your "own computer" to test across multiple machines.

If correctness of your system does not depend on real-time response, then it can be tested fairly accurately, although certain error conditions will never occur.

If results depend on various real time and time-based criteria, then most likely no. Testing a FPS on localhost is effectively not viable.

For one, traffic on localhost typically bypasses network card and driver, resulting in completely different usage patterns. There is also no extra latency introduced by LAN or other unexpected issues (unusual latency between two cards or two versions of network stack or router issues or ....).

But, more commonly, one needs the "normal" conditions to be WAN, with 10% packet loss, 3kb bandwidth and 180ms latency. While this can be emulated locally, it'll often result in a distinctly different perceived feeling.

For this reason, logic and networking are often separated by a strict abstraction layer, so that correct functioning is guaranteed (to a large degree) by the abstraction itself. This isn't always possible, and is far from trivial to implement and is usually better to use a third-party solution.

For addition, there is certain amount of network emulator tools (hardware and software) allowing to model wan in your lan. Those tools usually allows to vary latency, bandwidth and packet loss, sometime jitter.

Hmm... I guess it depends on what you mean by "normal circumstances" and "very least" :-)... all of those things everyone said are critical for a functional app, but if you are just wanting to make sure the basic mechanics of your system are in place and sockets are opening correctly, etc., then you can definitely do that on a single machine.

Yes, you can test locally. A few good practices:

- Use VirtualPC to run a second host, if you're on Windows. That host won't have 3D graphics, so make it run a "dedicated server" mode of your code.

- Use KVM to run a second host, if you're on Linux. Again, generally no 3D graphics, so this is best for dedicated servers (or bot daemons).

- In your sending code, you can add an "evil" flag that will do one of four things to each packet (assuming UDP):
a. Send as normal and terminate
b. Drop the packet and terminate
c. Delay the packet for at least one frame and try again
d. Send the packet and try again

On a real network, the occurrence of b is no more than 2%, and the occurence of d is much less, but if you set the chance of each of the adversarial events to 10% or more, you'll give your code a good work-out on the receiving end.