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: Thursday, August 09, 2001 7:23 PM
Subject: Re: [Mockobjects-java-users] Advantage for In-Container vs Mock ?


> Vincent
>
> "fancy name ! I am now wiser than before ... :)"
>
> Upon rereading that, I can only conclude that my inner academic made a
> stealthy strike before the send command. :)
>
> "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 ?"
>
> With a proxy, you generally only need to mock a couple specific methods
> rather than the whole interface. If an interface does not exist, then what
> are you going to do without inner classes to mock specific methods an
> implementation class?

I like the dynamic proxy because it enables to skip the static mock
implementation generation step. Even if you don't have an interface you can
still extend a class. The idea that the Mock Objects has been developing is
that the actual mock implementation could be generated because they do not
contain any logic code. For example, for each method XXX in the interface of
class to mock, a generation process could produce the following methods :

MockYYY.java

setActualValueXXX()
setExpectedValueXXX()
setActualExceptionXXX()
XXX()

And it can generate a verify() method for each mock class which will check
all setExpected*() methods.

so that it is up to the writer of the test case to say what he expects of
the call to XXX(), as in :

public void testSomething()
{
  MockYYY mock = new MockYYY();
  mock.setActualValueXXX("text/html");
  mock.setActualValueZZZ(true);
...
  // set the expectations on the mock object (if need be)
  mock.setExpectedValueAAA("something");
...
  // the method to unit test that calls XXX
  // and ZZZ as part of it's logic
  String result = myObject.someMethod();
...
  // then the asserts, which can be a mix of junit asserts and
  // verifying against the expectations set on the mock object
  assertEquals("...", result);
  mock.verify();
}

Now, the only questions which is not 100% answered (at least for what I
know) is : Is that mechanism going to work in 100% of cases or are there
cases where it won't work. I'm still looking for counter examples. But I
have not put it in practice either .... I need to use MO to understand
better what would be the limitations if any ... We probably need to work on
a real life example and see how it's unit tests are addressed by MO and
Cactus. I have a project in mind that would be a perfect live example for
that. I'll make a proposition shortly on both Cactus and MO lists on the
subject.

>
>  If you have the chance, I would like to see some code that allows for the
> setExpectedXXX() methods you are referring to. Is it in the mock object
> source that I have on hand? Do you have to write a special mock class for
an
> interface to track methods calls and parameters? If so, let's reverse the
> question and ask why write a library to set and test expectations when it
is
> easily done by using features of the platform itself?
>

The idea is simply that with the above described generic mechanism there is
no need to inner classes at all. But I may be wrong and I'd like to know the
counter arguments!

> Also, I don't want to get into too much detail until I get some feedback
> about the last version of the article I posted here, but the use of inner
> classes that set outer class variables makes the use of the Verifiable
> interface unnecessary in many cases. Furthermore, when you are testing the
> method of a particular class, you can override other methods of that same
> class to check expectations on inter-class calls.
>
> Tom
-Vincent