Which mock library do you prefer?

[Lacrima]

On Feb 15, 6:57 pm, Phlip <phlip2... at gmail.com> wrote:
> Lacrima wrote:
> > I am newbie mastering test driven development. I can't clarify myself
> > which mock library to use.
> > There are number of them and which one do you prefer?
>
> > Two libraries that attracted my attention are:
> > * minimock
> > * dingus
> > As for me the latest one, dingus, is the easiest (see this screencast:http://vimeo.com/3949077 ), but it has very few downloads from pypi,
> > so it scares me a little.
> > Minimock has wider usage and community, but I have some troubles using
> > it. Maybe I am wrong, but with minimock you always have to keep track
> > the order of imports in your test modules. Well, may be I just don't
> > understand fully how minimock works.
>
> > What are your suggestions?
>
> I have usedhttp://pypi.python.org/pypi/mock/0.6.0. It mocks, and it
> has a mode that works one method at a time, and another mode that
> mocks a method before its owning object gets constructed.
>
> However, TDD is not about mocking, and on greenfield code you should
> only mock to recover from some external problem, such as:
>
>      - a random number generator
>      - the system clock
>      - anything over "the wire" - over a TCP/IP socket
>      - hardware, such as your graphics or sound
>
> Never mock to avoid hitting the database. Some TDD verbiage advises
> "never hit the database". That is a mind-game to force you to decouple
> your code. Your objects should always have the option (via
> "construction encapsulation") to run as stubs, with some of their
> behaviors turned off. And if you TDD low-level code that hits a
> database, a mock would only tell the test what it wants to hear. And
> if you TDD high-level code that manages business rules, database
> records make perfectly good behavioral "fixtures" to support those
> rules.
>
> --
>   Phlip
>  http://c2.com/cgi/wiki?ZeekLand

Hi, Phlip!

Thanks for your reply! Isn't what you are talking about integration
tests? And unit tests should be fully isolated? So even for method
'some_method()' of class A I should mock instance of class A (i.e. to
mock 'self') to test 'some_method()'.

Please, could you explain in more detail your thoughts:
> Your objects should always have the option (via
> "construction encapsulation") to run as stubs, with some of their
> behaviors turned off. And if you TDD low-level code that hits a
> database, a mock would only tell the test what it wants to hear. And
> if you TDD high-level code that manages business rules, database
> records make perfectly good behavioral "fixtures" to support those
> rules.

And could you give an example.
For me it's really hard to develop test first. Often I don't know what
tests to write to replace hardcoded return values by objects that
perform actual work.
I have read several books on TDD and explored http://c2.com/cgi/wiki?TestDrivenDevelopment
and related wikis, but often it seems I don't have enough
understanding to write even simple application.
And sorry for my English.

with regards,
Max.