Shimming modules for testing (and fun)

Suppose that you have a chunk of Python code that wants to properly map IP addresses to hostnames, and you want to test this code to make sure that it actually works (especially with unit tests). In order to do this you need to contrive for various IP address and hostname lookups to fail in various ways, and to do this on command.

The easy way to do this is to exploit Python's freedom by shimming (well, replacing) the gethostbyname() and gethostbyaddr() functions in the socket module with completely fake versions, for example simple functions that just consult an internal table for the results they should return for various lookups. You then test your IP to hostname mapping code against these known fake IP addresses and make sure it returns correct results (since you already know what each IP address should result in; you specified it).

(Make sure that your test framework saves the original functions and puts them back into place after the test finishes; otherwise things may get very confused.)

Shimming ordinary module functions is usually a relatively simple thing (another useful module to shim is the time module, if you are testing time-dependent things). With more work you can shim entire classes, such as socket.socket, so that code that creates its own sockets and does things to them can be tested under completely controlled conditions.

(Watch out, though; it's easy for your shims to get overly complex and clever. I was probably there by the end of my unit testing fun. Also, remember to document what all of this clever testing code does, or you may have more excitement than you want in a year or so.)

Disclaimer: this is unlikely to be the officially TDD-approved way of unit testing this sort of stuff. But it has the two great virtues of not contorting your actual code and being relatively simple.