> Given the "duck typing" nature of the Python itself, it's pretty > trivial to build mocks without using any pre-built libraries.
I've also found it trivial to build a custom mock object whenever the need arises. > What is > less trivial and potentially more worthwhile is to have a library of > "stock" mock objects. . . . > 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. There's the rub. In writing tests, we frequently want to simulate only a tiny subset of behaviors and that subset varies dramatically depending on who is writing the test and what is being tested. For the most part, there is no "one size fits all". Given the ease of writing minimal, custom mock objects, I think it is not worthwhile to try to create a library of them. > 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. And also hard to learn, maintain, etc. When it comes to writing unittests, there is a distinct advangtage from writing your own, minimal mock objects. The writer knows exactly which behaviors are being modeled. In constrast, a library of heavy-weight mock objects promises to model many, but not all behaviors. Without a thorough knowledge of the library's fidelity, there is an undue risk of writing tests that look more thorough than they actually are. Likewise, there arises a double maitainance issue of keeping the mock object library in-sync with the real library being simulated. > Even keeping this problem in mind, it's still a reasonable idea for a > library, but obviously I'm biased. > > What do you think? I think it is like trying to market custom-cut, application specific duck tape. The generic tear-it-and-tape-it solution is far easier and more versatile than having a "library" of pre-cut tape. Raymond Hettinger -- http://mail.python.org/mailman/listinfo/python-list
