Saturday, November 28, 2009

mock tesing

been thinking about mock testing and i finally came to the point that i need it (to paper over some urllib calls). some googling around turned up a number of good links (an excellent list of python testing links, including mocking libs, etc., is at the cheesecake). there are also a couple of controversies roiling out there that i don't really care about, such as the difference between stubs and mocks (i'll use what works for me, whatever it's called) and if mocks are inherently evil (use them at i/o boundaries with external resources that are expensive, unpredictable, or unavailable). some of the mock frameworks out there seem to be derived from java libs, which is an auto strike against in my book. (java coders seem always to decide beforehand that a simple task needs 10k loc, even if they're writing python.) minimock looks interesting, and the only complaint i see for it is that it only works on doctests. i'm not sure that's even true anymore, and it's actively developed. since i only write doctests (i just can't see why it needs to be more complicated; another java arifact?), maybe it's exactly what i need. the examples on its website are easy to read and understand, and one of them shows how to use/mock smtp. one issue that i might run into later is wrapping vs. complete mocking. wrappers let you use the real object part of the time or for part of its interface. this can avoid some of the evilness criticism that the mocked code could change and break things without breaking the tests. i can imagine that sometimes it's less complicated, sometimes it's more.

No comments: