mockobjects-java-users — For people who use the mock objects libraries

[Mockobjects-java-users] JDBC 3.0 Complaint MockObjects

[Verma, N. (C. G. L529706) <Nit...@ge...>]

Hi All,

	I need MockCallableStatement(JDBC 3.0 complaint) and it wasn't there
in mock objects. So I mailed Steve.
	He told me to make myself and send it to MockObjects project
personal.
	Now my problem is I have to use it and I can't use as per my
management till the changes are not acceptable to
	the project managers/developers of mockobjects.... and these changes
come into mockobjects distribution.

	Please tell me how to get these changes in the MockObjects....?	

Regards,

Nitin Verma


"THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE
ADDRESSEE and may contain confidential and privileged information.
If the reader of this message is not the intended recipient,
you are notified that any dissemination, distribution or copy of this 
communication is strictly Prohibited. 
If you have received this message by error, please notify us 
immediately, return the original mail to the sender and delete the 
message from your system."

[Mockobjects-java-users] sql.MockPreparedStatement.setNull()

[Gauti R. <ga...@de...>]

Hi!

First of all, thanks for the framework... it's coming in handy so far
and I'm trying to learn how to use it best.

One question, why does setNull() throw an
UnsupportedOperationException???

I'm using this in a couple of places in my code, but I can't see why
this one should not be implemented by the mock objects, but most of the
other ones are???

cheers,

Gauti

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==

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

[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] 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

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

[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

[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

[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...>]

> > Of course, convergence of the two (dynamic / static) in naming and usage would
> > be fine, as it would give me freedom using both in the same project. (I would
> > not dare now.)
> 
> why not?

Because I find the techniques too new in order to mix them. Here I think more of
the other programmers, unfamiliar with all that, who eventually will have to
work with the code, and keep it up to state. It could be too confusing at the
first glance, EasyMock and real mockObjects.
In this sense, I would now try to stick to one of the two techniques.
But this will change, as mock-test-programming becomes an industry-standard.
in some years.


> No. We tend to fix code as we touch it. If you want to get involved that would be great.

I'll talk to you later about that, Steve. No time these days.


	Lucas

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

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

RnJvbTogIkx1Y2FzIEZpbHoiIDxsdWNhc0BoYWluYmFjaC5uZXQ+DQpUbzogPG1vY2tvYmplY3Rz
LWphdmEtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KU2VudDogU2F0dXJkYXksIFNlcHRl
bWJlciAxNSwgMjAwMSAzOjM4IFBNDQoNCg0KPiBUaGFuayB5b3UgVmluY2VudCAmIFN0ZXZlIGZv
ciB5b3VyIGFuc3dlcnMhIEkgc2VlIHlvdXIgcG9pbnRzLiANCj4gRXNwZWNpYWxseSB0aGUgc3Rh
bmRhcmQgQVBJIG1vY2tzISBBcmUgdGhlcmUgbW9yZSB0aGFuIHRoZSBvbmVzIGluDQo+IG1vY2tv
YmplY3RzLmphcj8gKHNvbWUgL2lvLCAvc2VydmxldCwgL3NxbCBhcyBmYXIgYXMgSSByZW1lbWJl
cikuDQo+IEFyZSB0aGVyZSBhbHJlYWR5IHNvbWUgbW9yZSBzb21ld2hlcmU/IFRpbSB0b2xkIG1l
IGF0IFhQMjAwMSB0aGF0IGhlL3lvdSBoYXZlDQo+IGFscmVhZHkgbW9ja2VkIGphdmFtYWlsLiBJ
cyB0aGF0IGF2YWlsYWJsZT8NCg0Kbm90IHlldC4gRmVlbCBmcmVlIHRvIGNvbnRyaWJ1dGUuIFRp
bSBoYXNuJ3QgcG9zdGVkIGFueSBmdXJ0aGVyIGxpYnJhcmllcy4NCg0KPiBBbm90aGVyIHBvaW50
IEkgc2VlIGlzIHRoYXQgaW4gdXNpbmcgRWFzeU1vY2sgdGhlcmUgcmVzdHMgc29tZSAna2luZCBv
ZiBtYWdpYycsDQo+IHdoZXJlYXMgdGhlIHJlYWwgbW9ja3MgYXJlIHNpbXBsZSBhbmQgZXZlcnl0
aGluZyBpcyB0aGVyZSB0byBpbnNwZWN0LiBNYXliZQ0KPiBlYXNpZXIgZm9yIGEgbmV3Y29tZXIg
dG9vLg0KDQpJJ2QgYmUgaW50ZXJlc3RlZCB0byBmaW5kIG91dCBpZiBvbmUgaXMgc2VlbiBhcyBl
YXNpZXIgdGhhbiB0aGUgb3RoZXIuDQoNCj4gT2YgY291cnNlLCBjb252ZXJnZW5jZSBvZiB0aGUg
dHdvIChkeW5hbWljIC8gc3RhdGljKSBpbiBuYW1pbmcgYW5kIHVzYWdlIHdvdWxkDQo+IGJlIGZp
bmUsIGFzIGl0IHdvdWxkIGdpdmUgbWUgZnJlZWRvbSB1c2luZyBib3RoIGluIHRoZSBzYW1lIHBy
b2plY3QuIChJIHdvdWxkDQo+IG5vdCBkYXJlIG5vdy4pDQoNCndoeSBub3Q/DQoNCj4gPiBUaGUg
aWRlYSBvZiB0aGUgTW9jayBPYmplY3RzIHByb2plY3QgaXMgdHdvZm9sZCA6IHByb3ZpZGUgYSBj
b3JlIGZyYW1ld29yaw0KPiA+IG9mIGV4cGVjdGF0aW9ucyBhbmQgdXNlZnVsIGNsYXNzZXMgZm9y
IHdyaXRpbmcgbW9jayBpbXBsZW1lbnRhdGlvbnMgKFRoaXMNCj4gPiBmcmFtZXdvcmsgaXMgYWN0
dWFsbHkgdXNlZCBieSBNb2NrTWFrZXIgdG8gZ2VuZXJhdGUgbW9jayBvYmplY3RzIGFuZCBpdA0K
PiA+IGNvdWxkIGJlIHVzZWQgYnkgRWFzeU1vY2sgdG9vKSANCj4gd2h5IGlzbid0IHRoYXQgdGhl
IGNhc2U/IEhhcyBzb21lYm9keSB0YWxrZWQgdG8gRWFzeU1vY2stVGFtbW8gRnJlZXNlIGFscmVh
ZHk/DQoNCndlJ2xsIHByb2JhYmx5IHNlZSBoaW0gYXQgT09QTFNBLiBJIHRoaW5rIGhlIGhhcyBz
b21lIGxpY2VuY2luZyBpc3N1ZXMuDQoNCj4gQnkgdGhlLnMgd2F5LCB3aGF0IGluIGRldGFpbCBu
ZWVkcyB0byBiZSBkb25lIGZvciB0aGUgb3BlbiB0YXNrOg0KPiANCj4gPiBXcml0ZSBhIGNvbW1v
biBjb2RpbmcgYW5kIG5hbWluZyBjb252ZW50aW9uIChmb3IgZXhhbXBsZSBuYW1lcw0KPiA+IG9m
IG1vY2sgaW5pdGlhbGl6YXRpb24gbWV0aG9kcyBsaWtlIHNldHVwQWRkUGFyYW1ldGVyKCksIG5h
bWUgb2YgbWV0aG9kcyANCj4gPiBmb3Igc2V0dGluZyBleHBlY3RhdGlvbnMsIC4uLikgYW5kIHJl
Zm9ybWF0IGFsbCB0aGUgZXhpc3RpbmcgY29kZS4NCj4gDQo+IFNvdW5kcyBsaWtlIHRoZXJlIGFy
ZSBuYW1pbmcgaW5jb25zaXN0ZW5jaWVzIGluIG1vY2tvYmplY3RzLmphci4NCg0KbW9zdCBsaWtl
bHkuIFNvbWUgb2YgdGhlIGNsYXNzZXMgaGF2ZW4ndCBiZWVuIGNoYW5nZWQgaW4gYSB3aGlsZS4N
Cg0KPiBJcyB0aGVyZSBhIGxpc3Qgb2YgdGhlIG1ldGhvZHMgbmVlZGluZyBwcm9wZXIgbmFtaW5n
Pw0KDQpOby4gV2UgdGVuZCB0byBmaXggY29kZSBhcyB3ZSB0b3VjaCBpdC4gSWYgeW91IHdhbnQg
dG8gZ2V0IGludm9sdmVkIHRoYXQgd291bGQgYmUgZ3JlYXQuDQoNClN0ZXZlDQoNCg0K

[Mockobjects-java-users] MockCreator for Visual Age

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

Hi,

Apologies to those, who already know: We just released "yet another"
mock generator, the MockCreator, this one is tightly integrated with
Visual Age for Java. (see
http://www.abstrakt.de/mockcreator/mockcreator.en.html for details and
download). It's free (license is GNU: GPL and LGPL)
(This announcement was made on behalf of Christian, who has done almost
all of the work)

We headed for our own way because we wanted the generator integrated in
VAJ (thus no MockMaker) couldn't use EasyMock (because of Java 1.2 in
VAJ).

We'd be happy to get some feedback on the MockCreator. btw: It makes
good use of the mockobjects.jar implementation in the generated classes
(especially the collections).

Have a nice weekend,

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] EasyMock vs. MockObjects

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

Thank you Vincent & Steve for your answers! I see your points. 
Especially the standard API mocks! Are there more than the ones in
mockobjects.jar? (some /io, /servlet, /sql as far as I remember).
Are there already some more somewhere? Tim told me at XP2001 that he/you have
already mocked javamail. Is that available?

Another point I see is that in using EasyMock there rests some 'kind of magic',
whereas the real mocks are simple and everything is there to inspect. Maybe
easier for a newcomer too.

Of course, convergence of the two (dynamic / static) in naming and usage would
be fine, as it would give me freedom using both in the same project. (I would
not dare now.)

> The idea of the Mock Objects project is twofold : provide a core framework
> of expectations and useful classes for writing mock implementations (This
> framework is actually used by MockMaker to generate mock objects and it
> could be used by EasyMock too) 

why isn't that the case? Has somebody talked to EasyMock-Tammo Freese already?


Steve:
> That said, there are now several tools based around mock objects and it
> seems like it would be a good idea to attempt some convergence. Any
> offers?

you mean founding the MOMG ?

What I can offer is 'opening the discussion'.


By the.s way, what in detail needs to be done for the open task:

> Write a common coding and naming convention (for example names
> of mock initialization methods like setupAddParameter(), name of methods 
> for setting expectations, ...) and reformat all the existing code.

Sounds like there are naming inconsistencies in mockobjects.jar.
Is there a list of the methods needing proper naming?


Nice weekend,

	Lucas



  Lucas Filz
  A-1140 Vienna
  +43.1.577 1 899

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

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

RnVydGhlciB0byBWaW5jZW50J3MgcG9zdGluZy4NCg0KLSBzb21lIG9mIHVzIHdlcmUgc3R1Y2sg
aW4gSmF2YSAxLjIgKHRoYW5rcyB0byBWaXN1YWxBZ2UpIGFuZCBzbyBkaWQgbm90IGhhdmUgcHJv
eGllcy4gVGhlcmUgYXJlIHN0aWxsIHZlcnNpb25zIG9mIEphdmEgKGVtYmVkZGVkKSB3aGljaCBk
byBub3Qgc3VwcG9ydCB0aGVtLg0KLSBTb21ldGltZXMgeW91IG5lZWQgdG8gbW9jayB1cCBhIGNs
YXNzLCByYXRoZXIgdGhhbiBhbiBpbnRlcmZhY2UNCi0gSXQgaGVscHMgdG8gZGlzdGluZ3Vpc2gg
YmV0d2VlbiB0aGUgc3R1YiBhbmQgdGhlIGFzc2VydGlvbiBhc3BlY3RzIG9mIGEgbW9jayBpbXBs
ZW1lbnRhdGlvbi4NCi0gaXQncyBwcm9iYWJseSB3b3J0aCBidWlsZGluZyBjb21tb24gaW1wbGVt
ZW50YXRpb25zIG9mIHN0YW5kYXJkIEFQSSdzIGFzIGEgbWVjaGFuaXNtIGZvciBzaGFyaW5nIGV4
cGVyaWVuY2UuIFRoZXJlIG1heSBiZSBtb3JlIHRoYW4gb25lLg0KDQpUaGF0IHNhaWQsIHRoZXJl
IGFyZSBub3cgc2V2ZXJhbCB0b29scyBiYXNlZCBhcm91bmQgbW9jayBvYmplY3RzIGFuZCBpdCBz
ZWVtcyBsaWtlIGl0IHdvdWxkIGJlIGEgZ29vZCBpZGVhIHRvIGF0dGVtcHQgc29tZSBjb252ZXJn
ZW5jZS4gQW55IG9mZmVycz8NCg0KU3RldmUNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t
LSANCkZyb206ICJMdWNhcyBGaWx6IiA8bHVjYXNAaGFpbmJhY2gubmV0Pg0KVG86IDxtb2Nrb2Jq
ZWN0cy1qYXZhLXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldD4NClNlbnQ6IEZyaWRheSwgU2Vw
dGVtYmVyIDE0LCAyMDAxIDc6MzEgUE0NClN1YmplY3Q6IFtNb2Nrb2JqZWN0cy1qYXZhLXVzZXJz
XSBFYXN5TW9jayB2cy4gTW9ja09iamVjdHMNCg0KDQo+IFVwIHRvIG5vdyBJJ20ganVzdCByZWFk
aW5nIGFib3V0IGFsbCB0aGF0LCBhbmQgbWF5YmUgSSBoYXZlIG1pc3NlZCBzb21ldGhpbmcsDQo+
IGJ1dDoNCj4gDQo+IFdoeSBjcmVhdGluZywgaGFuZGxpbmcsIHJlZmFjdG9yaW5nIGFsbCB0aG9z
ZSBNb2NrT2JqZWN0cyB3aGVuIHRoZXJlIGlzIHN1Y2ggYQ0KPiB0aGluZyBhcyBFYXN5TW9jaz8g
KFdyaXRpbmcgYW4gaW50ZXJmYWNlIGlmIHRoZXJlIGlzIG5vbmUgaXMgbm90IHRoZSBwb2ludCBJ
DQo+IGd1ZXNzLikNCj4gDQo+IFdoYXQgYXJlIHRoZSBkaXNhZHZhbnRhZ2VzIGluIHVzaW5nIEVh
c3lNb2NrPw0KPiANCj4gT3IsIHdoYXQgYXJlIHRoZSBhZHZhbnRhZ2VzIGluIGhhdmluZyB0aGUg
InJlYWwgbW9jayBvYmplY3QiIGF0IGhhbmQ/DQoNCg==

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

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

----- Original Message -----
From: "Lucas Filz" <lu...@ha...>
To: <moc...@li...>
Sent: Friday, September 14, 2001 7:31 PM
Subject: [Mockobjects-java-users] EasyMock vs. MockObjects


> Up to now I'm just reading about all that, and maybe I have missed
something,
> but:
>
> Why creating, handling, refactoring all those MockObjects when there is
such a
> thing as EasyMock? (Writing an interface if there is none is not the point
I
> guess.)
>
> What are the disadvantages in using EasyMock?
>
> Or, what are the advantages in having the "real mock object" at hand?
>

The short answer is : the two methods (dynamic and static) are
complementary. Why ? Because it is not always possible to generate good mock
implementations. I'll give a simple example. Lets imagine you want to use a
mock implementation of ServletOutputStream because you'd like to assert the
result from an HTTP response. This class only has print() methods but no
getter to access the content. Also what you'd like to do is to assert the
full string that has been written to the stream and not byte by byte. This
requires some intelligence that cannot be implemented automatically by
EasyMock or a static generation (MockMaker). You'll also find that you'll
discover patterns in your test case and you'll want to factorise these
patterns in the mock objects to provide consistency of checks and easier
writing of tests.

Now, it probably depends on the kind of API you are mocking and some will be
easily mocked with EasyMock. Others won't. I guess that a practice would be
to use automatic generation (be it dynamic or static) and then manually
write or modify the mocks (for those statically generated). Thus, the
problem is that EasyMock or MockMaker won't provide in-the-box and ready to
use mock objects (some will need to be written by hand or modified).

The idea of the Mock Objects project is twofold : provide a core framework
of expectations and useful classes for writing mock implementations (This
framework is actually used by MockMaker to generate mock objects and it
could be used by EasyMock too) and some prepackaged and already written mock
implementations for some standard APIs. The idea is that these API will be
feature complete (ok, I agree, there is still some work to be done ... :) )
and will have been fine tuned to already provide the patterns I mentionned
above (i.e. shortcuts for easy testing).

Tell me what you think. I'd like to hear from others too.

Thanks
-Vincent Massol

[Mockobjects-java-users] EasyMock vs. MockObjects

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

Up to now I'm just reading about all that, and maybe I have missed something,
but:

Why creating, handling, refactoring all those MockObjects when there is such a
thing as EasyMock? (Writing an interface if there is none is not the point I
guess.)

What are the disadvantages in using EasyMock?

Or, what are the advantages in having the "real mock object" at hand?

Thank you,

	Lucas

Re: [Mockobjects-java-users] ExpectationMap.myKeys is ExpectationSet - really want Lists

[Stephen or C. P. <csp...@ya...>]

Hi Steve,

--- Steve Freeman <st...@m3...> wrote:
> Interesting idea. Is this a pattern you've found yourself
> writing (that's how the expectation map got written)?
Yes, I have a specific situation.  It may be so uncommon that
you guys may decide it isn't worthwhile to put in this
additional function, but I think I will need to enhance
mockObjects myself (someday) even if it isn't adopted by others.

Or perhaps the code design that is requires this feature is
flawed?
> 
> The thing I would like to understand is how a 'KeyedList' (or
> whatever) would be better than an ExpectationList and pulling
> values off a regular collection. I'm still a little doubtful..

I need to test a method that has a loop that retries a sequence
of operations until a certain result is obtained.  The exit
condition for the loop is set by the results returned from an
ExpectationList input.  In order to do more than one iteration
in my method under test, I need the mockObject to return back a
sequence of responses, where the first and second input is
identical but the 1st response does not satisfy the loop
termination condition, and the 2nd response does satisfy it.

I haven't been doing OOD for very long, so my approach may be
faulty, but here is the code, where everything was done via
mockObjects and TfD, up to where the while loop was added:
The following are my first 3 unit-tests, and my 4th unit-test
which I could not implement without this enhancement:

public void test01SetLockWhenNoLockFound() throws Exception {
 myQueryStrings.addExpectedMissing(
  "delete from galaxy.lock_dimension where tabschema='GALAXY' "+
  "and tabname='TABLE_ABC' "+
  "and lck_tmstmp + 24 hours > CURRENT TIMESTAMP");

 myQueryStrings.addExpectedMissing(
  "insert into galaxy.lock_dimension values "+
  "('GALAXY','TABLE_ABC','user123',CURRENT TIMESTAMP)");

 myQueryStrings.addExpected(
  "select lck_user_id, lck_tmstmp from "+
  "galaxy.lock_dimension "+
  "where tabschema='GALAXY' and tabname='TABLE_ABC' for read
only",
  new
General1().tokensToVector("user123,2001-08-23-15.04.18.351858")
 );

 tableLock.setLock(queries, "user123", "GALAXY", "TABLE_ABC",
24,
  new MockLockStatus()  );
 myQueryStrings.verify();
}

public void test02SetLockWhenLockFoundDifferentUser() throws
Exception {
 myQueryStrings.addExpectedMissing(
  "delete from galaxy.lock_dimension where tabschema='GALAXY' "+
  "and tabname='TABLE_ABC' "+
  "and lck_tmstmp + 24 hours > CURRENT TIMESTAMP");

 myQueryStrings.addExpected(
  "insert into galaxy.lock_dimension values "+
  "('GALAXY','TABLE_ABC','user123',CURRENT TIMESTAMP)",
  new SQLException("tabschema/tabname duplicate
key","sqlstate",-803) );

 myQueryStrings.addExpected(
  "select lck_user_id, lck_tmstmp from "+
  "galaxy.lock_dimension "+
  "where tabschema='GALAXY' and tabname='TABLE_ABC' for read
only",
  new
General1().tokensToVector("user789,2001-08-23-15.04.18.351858")
 );

 tableLock.setLock(queries, "user123", "GALAXY", "TABLE_ABC",
24,
  new MockLockStatus() );
 myQueryStrings.verify();

}

public void test03SetLockWhenLockFoundSameUser() throws
Exception {
 myQueryStrings.addExpectedMissing(
  "delete from galaxy.lock_dimension where tabschema='GALAXY' "+
  "and tabname='TABLE_ABC' "+
  "and lck_tmstmp + 24 hours > CURRENT TIMESTAMP");

 SQLException sqlException = new SQLException(null,null,-803);
 myQueryStrings.addExpected(
  "insert into galaxy.lock_dimension values "+
  "('GALAXY','TABLE_ABC','user123',CURRENT TIMESTAMP)",
  sqlException );

 myQueryStrings.addExpected(
  "select lck_user_id, lck_tmstmp from "+
  "galaxy.lock_dimension "+
  "where tabschema='GALAXY' and tabname='TABLE_ABC' for read
only",
  new
General1().tokensToVector("user123,2001-08-23-15.04.18.351858")
 );

 myQueryStrings.addExpectedMissing(
  "update galaxy.lock_dimension "+
  "set lck_tmstmp=CURRENT TIMESTAMP "+
  "where tabschema='GALAXY' and tabname='TABLE_ABC'");

 tableLock.setLock(queries, "user123", "GALAXY", "TABLE_ABC",
24,
  new MockLockStatus());
 myQueryStrings.verify();
}
/******************************
 * cannot do this test without enhanced MockObject framework. 
Have a loop
 * that keeps retrying until a result comes back that says who
made the
 * preceeding insert fail.
 */
public void xtest04SetLockFoundRowButNoInfo() throws Exception {
 myQueryStrings.addExpectedMissing(
  "delete from galaxy.lock_dimension where tabschema='GALAXY' "+
  "and tabname='TABLE_ABC' "+
  "and lck_tmstmp + 24 hours > CURRENT TIMESTAMP");

 SQLException sqlException = new SQLException(null,null,-803);
 myQueryStrings.addExpected(
  "insert into galaxy.lock_dimension values "+
  "('GALAXY','TABLE_ABC','user123',CURRENT TIMESTAMP)",
  sqlException );

 myQueryStrings.addExpectedMissing(
  "select lck_user_id, lck_tmstmp from "+
  "galaxy.lock_dimension "+
  "where tabschema='GALAXY' and tabname='TABLE_ABC' for read
only");

 tableLock.setLock(queries, "user123", "GALAXY", "TABLE_ABC",
24,
  new MockLockStatus());
 myQueryStrings.verify();

}
---------
and here is the instance method that is under test:
---------

public void setLock(Queries queries, String userid, String
tabSchema, String tabName,
 int hoursTillStale, MultiRowObject lockStatus) throws Exception
{

 String rmStaleLock = "delete from galaxy.lock_dimension where
tabschema='"+
  tabSchema+"' and tabname='"+tabName+"' "+
  "and lck_tmstmp + "+hoursTillStale+
  " hours > CURRENT TIMESTAMP";
 String insertLock = "insert into galaxy.lock_dimension values
"+
  "('"+tabSchema+"','"+tabName+"','"+userid+"',CURRENT
TIMESTAMP)";
 String updateTime = "update galaxy.lock_dimension "+
  "set lck_tmstmp=CURRENT TIMESTAMP "+
  "where tabschema='"+tabSchema+"' and tabname='"+tabName+"'";
 String getLockInfo = "select lck_user_id, lck_tmstmp from "+
  "galaxy.lock_dimension "+
  "where tabschema='"+tabSchema+"' and tabname='"+tabName+"' for
read only";

 queries.runExecUpdate(rmStaleLock);

 String lockingUser = null;
 while ((lockingUser == null) || lockingUser.equals("") ) {
  try {
   queries.runExecUpdate(insertLock);
  }
  catch (SQLException e) {
   if (e.getErrorCode() == -803) {
    lockingUser = getLockHolder(lockStatus, queries,
getLockInfo);
    if ((lockingUser != null) && (lockingUser.equals(userid)))
     queries.runExecUpdate(updateTime);
   }
   else throw e;
  }
  lockingUser = getLockHolder(lockStatus, queries, getLockInfo);
 }
}
/*******/
public String getLockHolder(MultiRowObject lockStatus, Queries
queries, String g
etLockInfo)
throws Exception {
 queries.runQuery(getLockInfo, lockStatus);
 return ((IntLockStatus)lockStatus).getUser();
}
-----------
I apologize for the annoying line-breaks, and the un-refactored
portions of the code, but this is what triggered my initial
email.

Thanks again for your input.



__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

[Mockobjects-java-users] ExpectationMap.myKeys is ExpectationSet - really want Lists

[Stephen or C. P. <csp...@ya...>]

Hi,
Here is an enhancement idea which would help me and maybe make
the mockobjects framework more versatile.

Instead of having the addExpected(key, value) method only
available in the ExpectationMap class, could we have an
addExpected(key, value) method also in the ExpectationList
class, where two Lists are used for the key and value,
respectively, instead of a Map (Also, perhaps the key and value
nomenclature would need to be adjusted, like input and
response)?

This is driven by the situation where a test requires a
mockObject that must return results for various inputs, whereby
the inputs/results relationship is order-dependant.  For
example, the same input could be specified two times, and I
might require a specific result on the 2nd occurance that is
different from the 1st occurance of the input.

Ideally I could express my idea best by putting some unit-tests
together illustrating my issue.  I fear this is a bit beyond me
at present, but hope to get there eventually.

comments? 

thanks

Stephen Peterson



__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

Re: [Mockobjects-java-users] What is the correct way of writing this test ?

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

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: "Vincent Massol" <vm...@oc...>
Sent: Thursday, September 06, 2001 11:18 AM
Subject: Re: [Mockobjects-java-users] What is the correct way of writing
this test ?


> > I am trying to find out if a generic way of writing mocks is possible
and if
> > a tool like MockMaker would be good enough. My question is thus: what
would
> > be the algorithm for generating a mock implementation of
ServletOutputStream
>
> I'm sure that many mocks can be generated automatically, but not all.
Unfortunately, output stream is a bad candidate because you shouldn't put
too many restrictions on how the write methods are called. So, a stub
implmenentation is as good as any and you can mess with the contents after
the test. What's more interesting is to move to some kind of intermediate
object as soon as possible so that you can put some structure in the code --
at which point a mock makes is more useful.
>

I'm not sure I agree with "many mocks can be generated automatically" ... I
was just trying to convert my Cactus test cases into Mock Objects one to see
how the test would differ. I also wanted to use generated mocks to see if it
is usable. I started translating the first test ... and hit the
ServletOutputStream issue ...

I'm not sure I undestand the intermediate object you are referring to. Can
you give an example on the test case I have written :

{
      SampleServlet servlet = new SampleServlet();
      MockHttpServletRequest request = new MockHttpServletRequest();
      MockHttpServletResponse response = new MockHttpServletResponse();

      MockServletOutputStream output = new MockServletOutputStream();

      output.setExpectedContent("<h1>A request</h1>");
      response.setupOutputStream(output);

      servlet.doGet(request, response);

      output.verify();
}

Thanks
-Vincent

Re: [Mockobjects-java-users] What is the correct way of writing this test ?

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

Steve,

I am trying to find out if a generic way of writing mocks is possible and if
a tool like MockMaker would be good enough. My question is thus: what would
be the algorithm for generating a mock implementation of ServletOutputStream
?

Thanks
-Vincent

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: "Vincent Massol" <vm...@oc...>
Sent: Wednesday, September 05, 2001 6:28 PM
Subject: Re: [Mockobjects-java-users] What is the correct way of writing
this test ?


> This is example is OK as a very first cut at writing a servlet test. You
would expect some kind of intermediate objects start to appear as soon as
things became much more complicated. You certainly can't look for expected
writes because of potential bufferings in the stream.
>
> setExpectedContent is not much different for a string than just getting it
at the end. One thing I have worked on is a setExpectedSegment, which checks
if a particular (small) substring is present. Either way, you should get
away from testing strings like this as soon as you can, but you need to
start somewhere.
>
> Steve
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@oc...>
> To: <moc...@li...>
> Sent: Wednesday, September 05, 2001 5:40 PM
> Subject: [Mockobjects-java-users] What is the correct way of writing this
test ?
>
>
> > Hi,
> >
> > I have a simpe servlet with a doGet() method that simply prints a text
to
> > the output stream. I would like to know what is the correct way of
writing a
> > unit test for that method. It seems the suggested way (from the Mock
Object
> > sample and source code of MockHttpServletResponse) is to write:
> >
> > {
> >       SampleServlet servlet = new SampleServlet();
> >       MockHttpServletRequest request = new MockHttpServletRequest();
> >       MockHttpServletResponse response = new MockHttpServletResponse();
> >
> >       servlet.doGet(request, response);
> >
> >       String expected = "<h1>A request</h1>";
> >       String result = response.getOutputStreamContents();
> >       assertEquals(expected, result);
> > }
> >
> > However, I don't believe this is the canonical way of writing this test.
I
> > think
> > it would be more appropriate and consistent to write (even if longer) :
> >
> > {
> >       SampleServlet servlet = new SampleServlet();
> >       MockHttpServletRequest request = new MockHttpServletRequest();
> >       MockHttpServletResponse response = new MockHttpServletResponse();
> >
> >       MockServletOutputStream output = new MockServletOutputStream();
> >
> >       output.setExpectedContent("<h1>A request</h1>");
> >       response.setupOutputStream(output);
> >
> >       servlet.doGet(request, response);
> >
> >       output.verify();
> > }
> >
> > Question 1 : What do you think ? Should the example be changed ? Should
the
> > MockHttpServletResponse.getOutputStreamContents() method be removed ?
> > Question 2 : Is it possible to automatically generate a mock of
> > ServletOutputStream ? It would certainly not generate a
setExpectedContent()
> > method, right ? It would maybe generate a setExpectedWrite() method but
that
> > would not represent the full buffer...  ServletOutputStream is an object
> > that gets written to by the method under test, which means we need some
> > accessors to get back the data. How can Mock Maker generate these
accessors
> > in a generic way ?
> >
> > Thanks
> > -Vincent
> >
> >
> > _______________________________________________
> > Mockobjects-java-users mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> >
>

[Mockobjects-java-users] What is the correct way of writing this test ?

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

Hi,

I have a simpe servlet with a doGet() method that simply prints a text to
the output stream. I would like to know what is the correct way of writing a
unit test for that method. It seems the suggested way (from the Mock Object
sample and source code of MockHttpServletResponse) is to write:

{
      SampleServlet servlet = new SampleServlet();
      MockHttpServletRequest request = new MockHttpServletRequest();
      MockHttpServletResponse response = new MockHttpServletResponse();

      servlet.doGet(request, response);

      String expected = "<h1>A request</h1>";
      String result = response.getOutputStreamContents();
      assertEquals(expected, result);
}

However, I don't believe this is the canonical way of writing this test. I
think
it would be more appropriate and consistent to write (even if longer) :

{
      SampleServlet servlet = new SampleServlet();
      MockHttpServletRequest request = new MockHttpServletRequest();
      MockHttpServletResponse response = new MockHttpServletResponse();

      MockServletOutputStream output = new MockServletOutputStream();

      output.setExpectedContent("<h1>A request</h1>");
      response.setupOutputStream(output);

      servlet.doGet(request, response);

      output.verify();
}

Question 1 : What do you think ? Should the example be changed ? Should the
MockHttpServletResponse.getOutputStreamContents() method be removed ?
Question 2 : Is it possible to automatically generate a mock of
ServletOutputStream ? It would certainly not generate a setExpectedContent()
method, right ? It would maybe generate a setExpectedWrite() method but that
would not represent the full buffer...  ServletOutputStream is an object
that gets written to by the method under test, which means we need some
accessors to get back the data. How can Mock Maker generate these accessors
in a generic way ?

Thanks
-Vincent

[Mockobjects-java-users] test2, please ignore

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

cGxlYXNlIGlnbm9yZQ0K

[Mockobjects-java-users] test please ignore

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

VGhpcyBpcyBhIHRlc3QNCg==