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
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
(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
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.
Comments on this page:Written on 26 May 2008.