Re: [Mockobjects-java-users] EasyMock vs. MockObjects

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

----- Original Message -----
From: "Tammo Freese" <tam...@of...>
To: <moc...@li...>
Sent: Thursday, September 20, 2001 2:05 PM
Subject: Re: [Mockobjects-java-users] EasyMock vs. MockObjects


> Hello Steve, Lucas, Vincent,
>
> the thread on EasyMocks vs. MockObjects is quite interesting.
> IMHO, there are two interesting comparisons combined in one here:
>
> 1) Generating Mock Objects vs. Writing Mock Objects
>
> Generated Mock Objects are fast available. As they have a
> predefined behavior, their code does not need not be read for
> understanding a test case that uses them.
>

Agreed for your own objects that are mocked. For standard APIs, written mock
objects are even more readily available if they are provided by the
framework. Also, only mock implementation of interfaces are readily
available (correct me if I'm wrong) and you still need to hand-create mocks
for abstract classes or plain classes (and there are quite a lot of these,
especially if you don't own the code ...)

> Hand-crafted mock objects take quite a lot of time. However,
> complex interfaces sometimes deserve this work, at least if
> the Mock Objects have to fulfill additional behavior (and these
> Mock Objects should be tested).

agreed.

>
> To understand a test case using written Mock Objects, either
> their code has to be read, or their behavior has to be known.

well, the Mock Objects project has defined naming conventions to try to
improve the consistency of the API. Provided this, it is quite easy to
understand a written mock. There might some additional shortcuts that need
to be understood though, but the benefit they provide probably overcomes the
learning curve ...

>
> 2) Generating Statically vs. Generating Dynamically
>
> Statically generated Mock Objects lead to a fast definition
> of mock objects that feel like hand-crafted mock objects,
> as the generated names can follow the same naming conventions.
> However, when refactoring is applied to an interface, there is
> some work involved to get the code running again.

yes. The advantage of statically mocks is that you can modify them to add
shortcuts or provide additional features that cannot be automatically
generated. I agree with the round trip problem (although this can be solved
with markers in the text or the like - same techniques as those used by
UML -> code generation tools but this is probably quite hard to implement.
Another solution is to script the new methods to add and the MockMaker-like
framework will read the script to generate all its methods + the ones that
you would have scripted. I know, it is not perfect.

>
> Dynamically generated Mock Objects do not require to
> interrupt the flow of code writing for introducing new Mock
> Objects,they are available immediately. And as they use the
> interface itself for recording a part of the behavior,
> they are quite stable when refactoring is done on the
> interface.

this is true but breaks very quickly when you writing mock against existing
API. For example, if you want to write simple unit tests for a servlet,
you'll find that even for the most basic example, it won't work ... (take
the ServletOutputStream abstract class, which is needed for almost any
servlet test).

> Method or Interface renaming does not break the
> test code. However, generated Mock Objects currently have
> technical limitations. And the code is harder to read than code
> using hand-crafted or statically generated mock objects.
>
>
>
> What do you think?
>

I think we have to differentiate :
* code that you own and that you can refactor so that EasyMock will work
nicely (it is good because this refactoring improves the code by introducing
interfaces everywhere)
* existing API and there it breaks quickly and only static mocks can work

-Vincent