[TIP] flexmock for Python

[Herman Sheremetyev]

On Thu, Nov 25, 2010 at 8:23 PM, Geoff Bache <geoff.bache at gmail.com> wrote:
> On Wed, Nov 24, 2010 at 7:35 PM, Kumar McMillan
> <kumar.mcmillan at gmail.com> wrote:
>> On Wed, Nov 24, 2010 at 7:27 AM, Herman Sheremetyev <herman at swebpage.com> wrote:
>>> To give a few reasons why you might be interested, here's a list of
>>> currently supported features:
>>>
>>> - unittest.TestCase integration
>>> - automatic expectation checking on tearDown
>>> - should_receive()
>>> - with_args() ['with' is reserved in python]
>>> - times() [as well as once, twice and never aliases]
>>> - and_return()
>>> - and_raise()
>>> - overriding new instances (on new-style objects)
>>> - parameter shortcuts for with_args/and_return
>>> - at_least/at_most expectation modifiers
>>> - proxying/spying using the pass_thru expectation modifier
>>>
>>> More complete usage docs available at:
>>>
>>> https://github.com/has207/flexmock/wiki/Documentation
>>>
>>> It's still evolving as I'm adding more features, but I'd be really
>>> interested in any feedback from the community.
>>
>> Hi Herman.
>> I'm not a heavy Ruby user but I think FlexMock has a great API.  In
>> fact, the API of Ruby's Mocha is pretty much identical.  I thought
>> Mocha made for very readible and concise mocking code so I created
>> Fudge for Python http://farmdev.com/projects/fudge/
>>
>> I was very hesitant to introduce yet another mocking library and
>> attempted to justify my efforts here:
>> http://farmdev.com/projects/fudge/why-fudge.html
>>
>> However, I like that people are generous enough to release so many
>> mocking libraries to the Python community.
>
> Hi Kumar, Herman,
>
> Yes, there really are quite an astonishing number of mocking libraries
> for Python (are we into double figures yet?). I'm struck by how
> similar many of them seem also.

Agreed about the large number of testing libraries. But I haven't
found anything in the Python world which performed automatic assertion
checking and provided terse syntax. Every other library I saw that
comes close in expressiveness requires you to either put some "verify"
method in the tearDown method, add decorators to your tests, or both,
in order to perform assertions.

A flexmock test is as simple as this:

from flexmock import FlexMock
class TestFoo(unittest.TestCase):
  def test_some_stuff(self):
    FlexMock(Foo).should_receive('method1').and_return('value').once
    # where Foo is some class, or instance of a class, or module
    # point being I don't want to care, it should just do the right thing
    run_some_code_that_should_exercise_that_method()

This will raise an exception if Foo.method1 isn't called exactly once.
If I leave off the "once" modifier then it just acts as a stub and
doesn't raise any errors whether the call has been made or not.

This is such a basic pattern that requires so much needless
boilerplate, or special casing for classes vs instances vs modules, in
all the other libraries I've found for Python.

But I'm less interested in turning this thread into a discussion of
other mocking libraries, and would like to hear any feedback from
people that give flexmock a try to let me know what to improve.

Cheers,

-Herman