On Feb 15, 6:57 pm, Phlip <phlip2...@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. -- http://mail.python.org/mailman/listinfo/python-list
