There is a (relatively) widely used technique in unit testing, called mock objects. There is even a pMock library which provides a Mock class for a Python environment.

Given the "duck typing" nature of the Python itself, it's pretty trivial to build mocks without using any pre-built libraries. What is less trivial and potentially more worthwhile is to have a library of “stock” mock objects.

For instance, I found myself re-implementing ConnectionStub class again and again for different projects. And there is no shortage of other good candidates as well: socket, web request/response, thread objects, etc. Someone on a Python mailing list asks whether anyone implemented a mock filesystem interface, for example.

Having a library of such mock classes, realizing widely-used and “heavy” interfaces may be a good idea.

The only real problem I can think of is whether it’s possible to make these mocks generic enough. Mocks often contain some (application-specific) hard-coded rules and data to realize desired behavior. For instance, socket mock may fail when user attempts to write a “foobar” string – and unit test will use this to check how code handle these kind of errors. These rules may be generalized but it may lead to mock classes becoming unwieldy.

Even keeping this problem in mind, it’s still a reasonable idea for a library, but obviously I’m biased.

What do you think?