[TIP] flexmock for Python

[Geoff Bache]

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.

And as I wrote on another thread, I'm also busy adding to the number
with "capturemock", though this is one I am quite confident is
different from the others :) It addresses itself more to the problem
of larger scale mocking in integration or functional tests than trying
to create isolated unit tests or drive development BDD-style.

As the name suggests, it operates on a "capture-replay" model, but not
in the sense EasyMock and imitators do.

EasyMock etc have a "record phase" at the start of the test which is
pretty much just a way to state some expectations, and then a "replay
phase" where the test is actually run. I mean actually allowing for
two ways of running the same test, one which uses the real code and
(re)captures the behaviour of certain specified modules or functions
to a file, and one which uses that interaction as a mock and can be
run without the real modules present at all.

Regards,
Geoff