Which mock library do you prefer?

[Albert van der Horst]

In article <e88f4781-4b1f-4a9d-8c61-3a13c854c280 at d27g2000yqn.googlegroups.com>,
Lacrima  <lacrima.maxim at gmail.com> wrote:
>On Feb 16, 10:30=A0pm, Ben Finney <ben+pyt... at benfinney.id.au> wrote:
>> Lacrima <lacrima.ma... at gmail.com> writes:
>> > And I have already refused to write totally isolated tests, because it
>> > looks like a great waste of time.
>>
>> It only looks like that until you chase your tail in a long, fruitless
>> debugging session because (you later realise) the behaviour of one test
>> is being affected by another. Test isolation is essential to ensure that
>> your tests are doing what you think they're doing.
>>
>> --
>> =A0\ =A0 =A0 =A0 =93A =91No=92 uttered from deepest conviction is better =
>and greater |
>> =A0 `\ =A0 =A0 =A0 than a =91Yes=92 merely uttered to please, or what is =
>worse, to |
>> _o__) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0avoid tr=
>ouble.=94 =97Mohandas K. Gandhi |
>> Ben Finney
>
>Hi!
>
>Right, isolation is essential. But I can't decide to which extent I
>should propagate isolation.
>For example, in "Python Testing: Beginner's Guide" by Daniel Arbuckle,
>author suggests that if you do unittesting you should isolate the
>smallest units of code from each other. For example, if you have a
>class:
>Class SomeClass(object):
>    def method1(self):
>        return 5
>    def method2(self):
>        return self.method1 + 10
>
>According to the book, if you want to test method2, you should isolate
>it from method1 and class instance('self').
>Other books are not so strict...
>
>And what should I follow as newbie?
>
>Currently, I don't create mocks of units if they are within the same
>class with the unit under test. If that is not right approach, please,
>explain what are best practices... I am just learning TDD..

Unit testing is a concept that goes well with functions without
side effects. If you have classes, that doesn't work so well.

For classes use cases are the way to go.
Think about it. The whole state of an object can affect the
way a method works. So effectively for a unit test you have
to put the object in a whole special fully controlled state.
The point of an object is that it can't have just any state, but only
those attained by calling methods properly. So you may find yourself
artificially imposing states on an object with great effort, and
expecting error detection where the errors cannot in fact occur etc.
etc.

Not that coming up with good use cases is easy, but at least
they are naturally related to your objects.

>
>with regards,
>Maxim

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert at spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst