Unit testing UDP socket handling code

Question

Are there any 'good' ways to cause a thread waiting on a recvfrom() call to become unblocked and return with an error?

The motivation for this is to write unit tests for a system which includes a unit that reads UDP datagrams. One of the branches handles errors on the recvfrom call itself. The code isn't required to distinguish between different types of errors, it just has to set a flag.

I've thought of closing the socket from another thread, or do a shutdown on it, to cause recvfrom to return with an error, but this seems a bit heavy handed. I've seen mention elsewhere that sending an over-sized packet would do it, and so set up an experiment where a 16K buffer was sent to a recvfrom waiting for just 4K, but that didn't result in an error. The recvfrom just return 4096, to indicate it had gotten that many bytes.

Answer 1

You could create a class around the network library and sometimes fail it based on some criteria. You could for example have this network layer fail based on a certain network performance levels, where you emulate errors at certain frequencies.

I have asked a similar question in the past that may help too.

Answer 2

I think that a somewhat heavy handed or tricky approach is probably necessary.

Have you tried using ioctl(sock, FIONBIO, to switch the socket into non-blocking mode?

Answer 3

The easiest would probably be sending a signal, though that depends on whether the original code has handlers setup.

Answer 4

I have never done this in C, but in C#/Java I create wrapper classes around Sockets, TCPClient, etc. Each wrapper class implements an interface I create that represents the methods I'm interested in using. This allows me to use the dependency injection pattern to inject Mocked or stubbed Sockets. Maybe this pattern can help, although you would have to translate for your language.

Answer 5

If the class you're testing is well isolated from the rest of your application, perhaps you could wholesale #include the .c source file from your unit test. Then you can use a macro to #define recvfrom(...) to your own private function solely within the test.

Note that this will expose your private implementation to the unit test; you should still test against the public interface and pretend you can't see the guts. It's pretty hacky, but it at least contains all the ugliness to your unit test, without disrupting the deliverable code.