mockobjects-java-users

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

[Tammo F. <tam...@of...>]

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.

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).

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

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.

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. 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?

-
Tammo

-
Tammo Freese
fr...@ac...

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

[Lucas F. <lu...@ha...>]

Hello Tammo, Steve, Vincent and everybody!

Fine that you joined in the discussion! I agree with what you wrote.
One question that came up is, if we could think of ways to get to some
convergence in the usage of EasyMock and real mocks (be it generated
/refactored or hand-crafted).

First thing would be considering naming. Maybe defining and following
some common naming conventions can help in a better understanding of a
testcode utilizing mock-objects, regardless of the method involved.

Any suggestions here?

	Lucas

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

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

----- Original Message -----
From: "Lucas Filz" <lu...@ha...>
To: <moc...@li...>
Sent: Friday, September 21, 2001 11:49 AM
Subject: Re: [Mockobjects-java-users] EasyMock vs. MockObjects


> Hello Tammo, Steve, Vincent and everybody!
>
> Fine that you joined in the discussion! I agree with what you wrote.
> One question that came up is, if we could think of ways to get to some
> convergence in the usage of EasyMock and real mocks (be it generated
> /refactored or hand-crafted).
>
> First thing would be considering naming. Maybe defining and following
> some common naming conventions can help in a better understanding of a
> testcode utilizing mock-objects, regardless of the method involved.
>
> Any suggestions here?
>

I agree for naming conventions. The Mock Objects project has tried to
defined such a convention. It is available at
http://mockobjects.sourceforge.net/naming_conventions.html. We can accept
comments and modifications if need be to reach a consensus.

-Vincent

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

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

[Steve F. <st...@m3...>]

RnJvbTogIlRhbW1vIEZyZWVzZSIgPHRhbW1vLmZyZWVzZUBvZmZpcy5kZT4NCj4gMSkgR2VuZXJh
dGluZyBNb2NrIE9iamVjdHMgdnMuIFdyaXRpbmcgTW9jayBPYmplY3RzDQo+IA0KPiBHZW5lcmF0
ZWQgTW9jayBPYmplY3RzIGFyZSBmYXN0IGF2YWlsYWJsZS4gQXMgdGhleSBoYXZlIGENCj4gcHJl
ZGVmaW5lZCBiZWhhdmlvciwgdGhlaXIgY29kZSBkb2VzIG5vdCBuZWVkIG5vdCBiZSByZWFkIGZv
cg0KPiB1bmRlcnN0YW5kaW5nIGEgdGVzdCBjYXNlIHRoYXQgdXNlcyB0aGVtLg0KPiANCj4gSGFu
ZC1jcmFmdGVkIG1vY2sgb2JqZWN0cyB0YWtlIHF1aXRlIGEgbG90IG9mIHRpbWUuIEhvd2V2ZXIs
DQo+IGNvbXBsZXggaW50ZXJmYWNlcyBzb21ldGltZXMgZGVzZXJ2ZSB0aGlzIHdvcmssIGF0IGxl
YXN0IGlmDQo+IHRoZSBNb2NrIE9iamVjdHMgaGF2ZSB0byBmdWxmaWxsIGFkZGl0aW9uYWwgYmVo
YXZpb3IgKGFuZCB0aGVzZQ0KPiBNb2NrIE9iamVjdHMgc2hvdWxkIGJlIHRlc3RlZCkuDQoNCkEg
bG90IG9mIHRoZSBpc3N1ZXMgd2l0aCB3cml0aW5nIE1vY2tzIGJ5IGhhbmQgYXJlIHRvIGRvIHdp
dGggdGhlIGluYWRlcXVhY2llcyBvZiBvdXIgSURFcy4gVG9vbHMgbGlrZSBOZXRCZWFucyBhbmQg
SWRlYWogaGF2ZSBzb21lIG5pY2UgZmVhdHVyZXMgZm9yIGtlZXBpbmcgaW4gc3luYy4gV2UgcmVh
bGx5IHNob3VsZG4ndCBoYXZlIHRvIGRvIHRvbyBtdWNoIHRvIG1ha2Ugc29tZXRoaW5nIHdvcmsg
LS0gb25lIGRheS4NCiANCj4gVG8gdW5kZXJzdGFuZCBhIHRlc3QgY2FzZSB1c2luZyB3cml0dGVu
IE1vY2sgT2JqZWN0cywgZWl0aGVyDQo+IHRoZWlyIGNvZGUgaGFzIHRvIGJlIHJlYWQsIG9yIHRo
ZWlyIGJlaGF2aW9yIGhhcyB0byBiZSBrbm93bi4NCg0KV2UgaGF2ZW4ndCBmb3VuZCB0aGlzIHRv
IGJlIGEgcHJvYmxlbS4gSXQgc2hvdWxkIGJlIHJlYXNvbmFibHkgb2J2aW91cy4NCg0KVGhlIHJl
YWxseSBpbnRlcmVzdGluZyBkaWZmZXJlbmNlIGlzIHRoYXQgdGhlcmUgaXMgYSByaXNrIHdpdGgg
ZHluYW1pYyBtb2NrcyB0aGF0IHRoZSB0ZXN0IG92ZXJzcGVjaWZpZXMgdGhlIGJlaGF2aW91ciBv
ZiB0aGUgdGFyZ2V0IGNvZGUuIFRoZSBvbmUgdGhpbmcgdGhhdCBoYW5kIE1vY2tzIG1ha2UgZXhw
bGljaXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgZXhwZWN0YXRpb24gYW5kIHN0dWIg
YXNwZWN0cyBvZiBhIG1vY2suIE9ubHkgdGhlIGV4cGVjdGF0aW9ucyBhcmUgcmVhbGx5IHBhcnQg
b2YgdGhlIHRlc3Q7IEkgdGhpbmsgdGhpcyBpcyBpbXBvcnRhbnQuIEkgaGF2ZSBzb21lIGlkZWFz
IGFib3V0IGhvdyB0aGlzIGNvdWxkIGJlIGRvbmUgZm9yIGR5bmFtaWMgbW9ja3MuDQoNCg0KPiAy
KSBHZW5lcmF0aW5nIFN0YXRpY2FsbHkgdnMuIEdlbmVyYXRpbmcgRHluYW1pY2FsbHkNCj4gDQo+
IFN0YXRpY2FsbHkgZ2VuZXJhdGVkIE1vY2sgT2JqZWN0cyBsZWFkIHRvIGEgZmFzdCBkZWZpbml0
aW9uDQo+IG9mIG1vY2sgb2JqZWN0cyB0aGF0IGZlZWwgbGlrZSBoYW5kLWNyYWZ0ZWQgbW9jayBv
YmplY3RzLA0KPiBhcyB0aGUgZ2VuZXJhdGVkIG5hbWVzIGNhbiBmb2xsb3cgdGhlIHNhbWUgbmFt
aW5nIGNvbnZlbnRpb25zLg0KPiBIb3dldmVyLCB3aGVuIHJlZmFjdG9yaW5nIGlzIGFwcGxpZWQg
dG8gYW4gaW50ZXJmYWNlLCB0aGVyZSBpcw0KPiBzb21lIHdvcmsgaW52b2x2ZWQgdG8gZ2V0IHRo
ZSBjb2RlIHJ1bm5pbmcgYWdhaW4uDQoNCklzIHRoaXMgcmVhbGx5IGEgcHJvYmxlbT8NCg0KPiBE
eW5hbWljYWxseSBnZW5lcmF0ZWQgTW9jayBPYmplY3RzIGRvIG5vdCByZXF1aXJlIHRvDQo+IGlu
dGVycnVwdCB0aGUgZmxvdyBvZiBjb2RlIHdyaXRpbmcgZm9yIGludHJvZHVjaW5nIG5ldyBNb2Nr
DQo+IE9iamVjdHMsdGhleSBhcmUgYXZhaWxhYmxlIGltbWVkaWF0ZWx5LiBBbmQgYXMgdGhleSB1
c2UgdGhlDQo+IGludGVyZmFjZSBpdHNlbGYgZm9yIHJlY29yZGluZyBhIHBhcnQgb2YgdGhlIGJl
aGF2aW9yLA0KPiB0aGV5IGFyZSBxdWl0ZSBzdGFibGUgd2hlbiByZWZhY3RvcmluZyBpcyBkb25l
IG9uIHRoZQ0KPiBpbnRlcmZhY2UuIE1ldGhvZCBvciBJbnRlcmZhY2UgcmVuYW1pbmcgZG9lcyBu
b3QgYnJlYWsgdGhlDQo+IHRlc3QgY29kZS4gSG93ZXZlciwgZ2VuZXJhdGVkIE1vY2sgT2JqZWN0
cyBjdXJyZW50bHkgaGF2ZQ0KPiB0ZWNobmljYWwgbGltaXRhdGlvbnMuIEFuZCB0aGUgY29kZSBp
cyBoYXJkZXIgdG8gcmVhZCB0aGFuIGNvZGUNCj4gdXNpbmcgaGFuZC1jcmFmdGVkIG9yIHN0YXRp
Y2FsbHkgZ2VuZXJhdGVkIG1vY2sgb2JqZWN0cy4NCg0KTXkgaXNzdWUgd2l0aCBnZW5lcmF0ZWQg
TW9ja3MgaXMgdGhhdCBpdCdzIHZlcnkgaGFyZCB0byBmaW5kIHRoZSByaWdodCBsZXZlbCBvZiBj
b2RlIGdlbmVyYXRpb24gZXhjZXB0IGZvciB2ZXJ5IHNpbXBsZSBvYmplY3RzLiBUaGVyZSBtYXkg
YmUgc29tZSB1c2VmdWwgdGhpbmdzIHdlIGNvdWxkIGRvIHRvIGdpdmUgaGludHMgdG8gdGhlIGNv
ZGUgZ2VuZXJhdG9yLg0KDQpTdGV2ZQ0KDQo=

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

[Lucas F. <lu...@ha...>]

Steve Freeman wrote:
> test overspecifies the behaviour of the target code. The one thing that 
> hand Mocks make explicit is the difference between the expectation and 
> stub aspects of a mock. Only the expectations are really part of the 
> test; I think this is important. I have some ideas about how this could 
> be done for dynamic mocks.


Steve, I would be very interested to read about your ideas. Could you 
please describe them?


> There may be 
> some useful things we could do to give hints to the code generator.

that as well


Thank you,
  Lucas