FAQ
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?

Search Discussions

  • Raymond Hettinger at Jun 9, 2005 at 10:19 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedJun 9, '05 at 10:28a
activeJun 9, '05 at 10:19p
posts2
users2
websitepython.org

2 users in discussion

Raymond Hettinger: 1 post Ischenko: 1 post

People

Translate

site design / logo © 2022 Grokbase