Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?

[Vincent M. <vm...@oc...>]

----- Original Message -----
From: "Thomas Calivera" <ald...@ne...>
To: <moc...@li...>;
<cac...@ja...>
Sent: Wednesday, August 08, 2001 4:26 PM
Subject: Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?


> Vincent
>
> "The getLocale() method is actually implemented in the Action class ... So
I
> can see 2 ways of coping with this :
> * Solution 1: Create a LogonActionForTest class that extends LogonAction
and
> override the getLocale() method so that it returns what we want,"
>
> If I am following this thread correctly, I think it is useful to consider
> that, although the article I posted earlier shows how to override methods
of
> objects passed in *as parameters*, the same technique is useful in
> overriding methods of the actual test subject during testing, as I think
you
> are realizing in terms of overriding the getLocale() method.
>

yep

> At first, it feels like a violation of the normative Heisenberg
uncertainty

fancy name ! I am now wiser than before ... :)

> principle because you are *changing the class you are testing*, but unit
> testing is concerned with particular *methods*, not classes. Therefore, as
> long as you do not override the method you are testing with the anonymous
> inner class, you can actually use an anonymous inner class to redefine an
> object you are about to test, including any methods except the one you are
> testing. I can provide a code example if necessary (I need to write one
for
> the article anyway).

I'm still not convinced of the advantage of these inner classes of yours ...
I don't see what advanatges it brings ... Because anyway you need an
implementation of the mock (be it static or dynamic). Now what remains is to
define your expectation on the mock object and this is easily done by use
method calls to setExpectedXXX()-like methods. Something I am missing ?

>
> Tom
-Vincent