mockobjects-java-users

[Mockobjects-java-users] MockCreator - interesting variation to setUp

[ivan m. <iva...@ya...>]

Hello fellow MockObject users,

I'd like people's opinions on the convention used by
the MockObjects created by MockCreator.
If you have a method:

int foo(String)

MockCreator creates a method:

expectFoo(String,int)

which sets the expectation for the method parameter
and
sets up the value that will be returned by that method
call rather than the "MockObjects convention"

setupFoo(int)

for setting the return value, and:

addExpectedFoo(String) [or setExpectedFoo(String) for
a single value]

for setting the expectation.

I don't know what this convention would be like to use
in practice. My fear is that I'd end up having to set
expectations where I only want to setup a return
value.
Similarly I might want only to set expectations but
not be bothered about the return values. Just to
stress the point - I don't know - these are
just fears and without using the mocks created by
MockCreator I don't know - so please could people
comment who have used the MockCreator conventions.

It might be that both styles could be used together,
with expectFoo(String,int) being a refactoring of
setupFoo(int);addExpectedFoo(String)?

Ivan


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

Re: [Mockobjects-java-users] MockCreator - interesting variation to setUp

[Olaf K. <ok...@ab...>]

Hi,

I'd like to comment on this, as MockCreator was assembled by my
colleague Christian, now on holiday. Sorry, this will be quite long, but
give some history of MockCreator to set a context in which our decisions
might be easier to understand.

During our history with MockObjects we have been frequently annoyed with
setting up quite some amount of expectations and return values.
This led to assembling the convenience-methods Ivan mentions: Setting
expected input and return value in one method call.

Further, the implementation of the base-MockObject we use
(de.abstrakt.mock.MockObject) forces us to set a return value if the
method returns non-void, otherwise we'll get out of sync within the
implementation (I know, this is a weak excuse).

We decided, that - using MockObjects a lot - it is a lot more convenient
to write 
 i.expectFoo( "something", 7 );
 i.expectBar( "a parameter", "dontcare" );
instead of
 i.setUpFoo( 7 );
 i.addExpectedFoo( "Something" );
 i.setUpBar( "dontcare" );
 i.addExpectedBar( "a parameter" );

(given an interface like:)
 int foo(String);
 String bar( String );

Additionaly, for each mocked method there are two "expect"-methods:
 void expectFoo( String parameter, int returnvalue );
 void expectFoo( String parameter, Throwable throwable );
to be able to specify that an exception should be thrown upon call of
this method.
(we have realised that this is bad for methods legally _returning_ a
throwable and will most likely change the generated method name
slightly)

This leads to quite an amount of methods for each MockObject, but you're
right: You could use more. I favor setting the return value in any case,
even if you don't care. This means, you are forced to care and possibly
express your "dontcare" explicitly in code.
If you don't care about the incoming parameter, the world looks
different: You can't specify "dontcare" with MockCreator (yet?). It
would be easy to generate in the "int foo(String)" example, but what
about "int foo( String, int, MyBusinessObject )"? Which parameter is it,
you don't care about?
I suggest it would be best to provide a hook for easy hand-crafting of
this behaviour within the generated object (as well as a differential
generation if the implementation already exists).

Christian is currently extending the MockCreator to be able to specify
blocks of expectations where you don't care about the order of
execution. We have frequently been annoyed by data coming in in
particular order (especially if you are using Set or Map collections)
and thought it might be neat to abstract this out. Until now we didn't
care about having to specify too much input like you mentioned.

And: I suspect it would be fairly easy to extend the MockCreator to
mimic the "standard MockObjects behaviour" - additionaly. The most work
has to be done by the VA-Classbrowser: We already triple the number of
methods in each interface ;-)

What do other users think?

Olaf

-- 

abstrakt gmbh
Behringstrasse 16b (neu!)
22765 Hamburg
Tel: +49-40-39804630 (neu!)
Fax: +49-40-39907669
http://www.abstrakt.de/

Wir sind umgezogen. Bitte beachten 
Sie die neue Adresse + Telefonnummer

Re: [Mockobjects-java-users] MockCreator - interesting variation to setUp

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

RnJvbTogIk9sYWYgS29jayIgPG9rb2NrQGFic3RyYWt0LmRlPg0KPiBEdXJpbmcgb3VyIGhpc3Rv
cnkgd2l0aCBNb2NrT2JqZWN0cyB3ZSBoYXZlIGJlZW4gZnJlcXVlbnRseSBhbm5veWVkIHdpdGgN
Cj4gc2V0dGluZyB1cCBxdWl0ZSBzb21lIGFtb3VudCBvZiBleHBlY3RhdGlvbnMgYW5kIHJldHVy
biB2YWx1ZXMuDQo+IFRoaXMgbGVkIHRvIGFzc2VtYmxpbmcgdGhlIGNvbnZlbmllbmNlLW1ldGhv
ZHMgSXZhbiBtZW50aW9uczogU2V0dGluZw0KPiBleHBlY3RlZCBpbnB1dCBhbmQgcmV0dXJuIHZh
bHVlIGluIG9uZSBtZXRob2QgY2FsbC4NCj4gDQo+IEZ1cnRoZXIsIHRoZSBpbXBsZW1lbnRhdGlv
biBvZiB0aGUgYmFzZS1Nb2NrT2JqZWN0IHdlIHVzZQ0KPiAoZGUuYWJzdHJha3QubW9jay5Nb2Nr
T2JqZWN0KSBmb3JjZXMgdXMgdG8gc2V0IGEgcmV0dXJuIHZhbHVlIGlmIHRoZQ0KPiBtZXRob2Qg
cmV0dXJucyBub24tdm9pZCwgb3RoZXJ3aXNlIHdlJ2xsIGdldCBvdXQgb2Ygc3luYyB3aXRoaW4g
dGhlDQo+IGltcGxlbWVudGF0aW9uIChJIGtub3csIHRoaXMgaXMgYSB3ZWFrIGV4Y3VzZSkuDQo+
IA0KPiBXZSBkZWNpZGVkLCB0aGF0IC0gdXNpbmcgTW9ja09iamVjdHMgYSBsb3QgLSBpdCBpcyBh
IGxvdCBtb3JlIGNvbnZlbmllbnQNCj4gdG8gd3JpdGUgDQo+ICBpLmV4cGVjdEZvbyggInNvbWV0
aGluZyIsIDcgKTsNCj4gIGkuZXhwZWN0QmFyKCAiYSBwYXJhbWV0ZXIiLCAiZG9udGNhcmUiICk7
DQo+IGluc3RlYWQgb2YNCj4gIGkuc2V0VXBGb28oIDcgKTsNCj4gIGkuYWRkRXhwZWN0ZWRGb28o
ICJTb21ldGhpbmciICk7DQo+ICBpLnNldFVwQmFyKCAiZG9udGNhcmUiICk7DQo+ICBpLmFkZEV4
cGVjdGVkQmFyKCAiYSBwYXJhbWV0ZXIiICk7DQo+IFsuLi5dDQoNClRoZXJlIGEgYnVuY2ggb2Yg
aXNzdWVzIGhlcmUuDQotIG9uZSBvZiB0aGUgdGhpbmdzIHRoYXQgY29uY2VybnMgbWUgYWJvdXQg
dG9vbHMgbGlrZSBFYXN5TW9jayBpcyB0aGF0IGl0IGRvZXNuJ3QgbWFrZSBleHBsaWNpdCB0aGUg
ZGlzdGluY3Rpb24gYmV0d2VlbiB0aGUgc3R1YiBhbmQgZXhwZWN0YXRpb24gYXNwZWN0cyBvZiBh
IG1vY2sgb2JqZWN0LiBJJ20gaW5jcmVhc2luZ2x5IGNvbnZpbmNlZCBhYm91dCBob3cgaW1wb3J0
YW50IGl0IGlzLiANCi0geW91ciBleGFtcGxlIHN1Z2dlc3RzIHRoYXQgeW91IHZlcmlmeSBhbmQg
c3R1YiBldmVyeSBtZXRob2QgdGhhdCB0aGUgdGFyZ2V0IGNhbGxzIG9uIHRoZSBtb2NrLiBTb21l
dGltZXMgdGhlIHRyaWNrIGlzIHRvIGZpbmQgaG93IGxpdHRsZSB5b3UgY2FuIHNwZWNpZnkgaW4g
YSB0ZXN0IGNhc2UuDQotIHJhdGhlciB0aGFuIGNoYW5naW5nIHRoZSBtb2NrIGdlbmVyYXRvciwg
ZG8geW91IHRoaW5rIHRoYXQgeW91ciBwcm9ibGVtcyByZXByZXNlbnRlZCBhIGNvZGUgc21lbGwg
Zm9yIHlvdXIgdGFyZ2V0IGNvZGU/IEFyZSB5b3VyIG9iamVjdHMgc3RpbGwgdG9vIGxhcmdlIChJ
IGtub3cgdGhlcmUncyBub3QgbXVjaCB5b3UgY2FuIGRvIHdpdGggb3RoZXIgcGVvcGxlJ3MgbGli
cmFyaWVzKS4gDQotIHdoYXQgYXJlIHRoZSBpbnRlcmVzdGluZyBkaWZmZXJlbmNlcyBiZXR3ZWVu
IHlvdXIgYmFzZSBNb2NrT2JqZWN0IGFuZCBvdXJzPyBBcmUgd2UgbWlzc2luZyBhbnl0aGluZz8g
QXJlIHlvdT8NCg0KPiBUaGlzIGxlYWRzIHRvIHF1aXRlIGFuIGFtb3VudCBvZiBtZXRob2RzIGZv
ciBlYWNoIE1vY2tPYmplY3QsIGJ1dCB5b3UncmUNCj4gcmlnaHQ6IFlvdSBjb3VsZCB1c2UgbW9y
ZS4gSSBmYXZvciBzZXR0aW5nIHRoZSByZXR1cm4gdmFsdWUgaW4gYW55IGNhc2UsDQo+IGV2ZW4g
aWYgeW91IGRvbid0IGNhcmUuIFRoaXMgbWVhbnMsIHlvdSBhcmUgZm9yY2VkIHRvIGNhcmUgYW5k
IHBvc3NpYmx5DQo+IGV4cHJlc3MgeW91ciAiZG9udGNhcmUiIGV4cGxpY2l0bHkgaW4gY29kZS4N
Cg0KV2UgaGFkIGEgbG9uZyBhcmd1bWVudCBhYm91dCB0aGlzIGluIExvbmRvbiB3aGVuIGRlZmlu
aW5nIHRoZSBleHBlY3RhdGlvbiBjbGFzc2VzLiBJbiB0aGUgZW5kLCB0aGUgZGVmYXVsdCBiZWhh
dmlvdXIgaXMgcGVybWlzc2l2ZTogaWYgSSBkb24ndCBzZXQgYW55IGV4cGVjdGF0aW9ucywgdGhl
IG1vY2sgb2JqZWN0IGRvZXNuJ3QgY2FyZS4gV2UgaGF2ZSBhbiBleHBsaWNpdCBleHBlY3ROb3Ro
aW5nKCkgY2FsbC4gVGhpcyBtYWtlcyBsaWZlIG11Y2ggZWFzaWVyIHdoZW4gd29ya2luZyB3aXRo
IGRpZmZlcmVudCBmZWF0dXJlcyBvZiBhIG1vY2suDQoNClN0ZXZlDQoNCg==