mockobjects-java-users

[MO-java-users] any pattern for this?

[J. X. <sou...@ma...>]

The class I'm trying to mock is instantiated by a third part tool (castor xml 
unmarshaller in this case) that does not take any factory. My problem with this 
is that I don't have chance to set any expectations before the actual calls are 
made. How does everybody else handle cases like this with mock objects?

TIA.
--J.X.

Re: [MO-java-users] any pattern for this?

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

I don't understand. Are you trying to run your unit test within castor? 
Why can't you just create an instance?

S.

J. Xue wrote:

> The class I'm trying to mock is instantiated by a third part tool (castor xml 
> unmarshaller in this case) that does not take any factory. My problem with this 
> is that I don't have chance to set any expectations before the actual calls are 
> made. How does everybody else handle cases like this with mock objects?
> 
> TIA.
> --J.X.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> 

-- 
"A LISP programmer knows the value of everything but the cost of nothing.
  A C programmer knows the cost of everything but the value of nothing."
(Todd Proebsting)

Re: [MO-java-users] any pattern for this?

[J. X. <sou...@ma...>]

Quoting Steve Freeman <st...@m3...>:

> I don't understand. Are you trying to run your unit test within castor? 
> Why can't you just create an instance?

ClassUnderTest calls the castor XML Unmarshaller to load ClassToMock. For the 
test code to be able to sneak in a canned instance of ClassToMock, the only 
way I can think of now is to make ClassUnderTest call a factory instead of 
calling castor directly, but it would unnecessarily complicate the design 
since most of the code is closely tied to castor anyway.

--J.X.

Re: [MO-java-users] any pattern for this?

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

Sounds like you should wrap the unmarshaller in an interface that you 
control, like you say.

Joe Walnes has come up with the interesting concept that you should only 
mock types that you own, not third party types. It's an interesting 
twist that pushes you to write your code in terms of your domain, not in 
terms of your infrastructure. I've been doing a lot of this recently on 
.Net (thank you MS for your flexible libraries...) and it works nicely.

S.

J. Xue wrote:
> ClassUnderTest calls the castor XML Unmarshaller to load ClassToMock.
> For the test code to be able to sneak in a canned instance of
> ClassToMock, the only way I can think of now is to make
> ClassUnderTest call a factory instead of calling castor directly, but
> it would unnecessarily complicate the design since most of the code
> is closely tied to castor anyway.

Re: [MO-java-users] any pattern for this?

[Nat P. <nat...@b1...>]

Can't you mock the unmarshaller?

Cheers,
            Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: "J. Xue" <sou...@ma...>
To: "MockObjects Users" <moc...@li...>
Sent: Tuesday, December 16, 2003 11:29 PM
Subject: Re: [MO-java-users] any pattern for this?


> Quoting Steve Freeman <st...@m3...>:
>
> > I don't understand. Are you trying to run your unit test within castor?
> > Why can't you just create an instance?
>
> ClassUnderTest calls the castor XML Unmarshaller to load ClassToMock. For
the
> test code to be able to sneak in a canned instance of ClassToMock, the
only
> way I can think of now is to make ClassUnderTest call a factory instead of
> calling castor directly, but it would unnecessarily complicate the design
> since most of the code is closely tied to castor anyway.
>
> --J.X.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

Re: [MO-java-users] any pattern for this?

[J. X. <sou...@ma...>]

Quoting Nat Pryce <nat...@b1...>:

> Can't you mock the unmarshaller?

Well I thought about that, but first of all, wouldn't it go against the "Only 
Mock Your Own Interface" pattern?  Secondly, that'd require ClassUnderTest to 
call an adapter instead of calling the real unmarshaller directly (or do I just 
make the mock unmarshaller in the castor package and shadow the real one on the 
classpath?)  I wasn't sure either way would be a good idea...

--J.X.

Re: [MO-java-users] any pattern for this?

[Nat P. <nat...@b1...>]

On Wed, 2003-12-17 at 15:03, J. Xue wrote:
> Quoting Nat Pryce <nat...@b1...>:
> 
> > Can't you mock the unmarshaller?
> 
> Well I thought about that, but first of all, wouldn't it go against the "Only 
> Mock Your Own Interface" pattern?  

Yes.  And if you're going to only mock your own interfaces the whole
problem goes away, doesn't it?

But if you're not, then this would be a workaround

> Secondly, that'd require ClassUnderTest to 
> call an adapter instead of calling the real unmarshaller directly (or do I just 
> make the mock unmarshaller in the castor package and shadow the real one on the 
> classpath?)  I wasn't sure either way would be a good idea...

ClassUnderTest would call an interface to perform unmarshalling.  It
wouldn't care if the implementation of the interface was an adapter or a
direct implementation.  Whichever approach you take (adapter or mocking
castor), you'd put the mock unmarshaller into your own test package. 
There's no need to touch the castor packages.

Cheers,
	Nat.

Re: [MO-java-users] any pattern for this?

[J. X. <sou...@ma...>]

Quoting Nat Pryce <nat...@b1...>:

> ClassUnderTest would call an interface to perform unmarshalling.  It
> wouldn't care if the implementation of the interface was an adapter or a
> direct implementation.  Whichever approach you take (adapter or mocking
> castor), you'd put the mock unmarshaller into your own test package. 
> There's no need to touch the castor packages.

Yeah, it seems that an adapter is the most viable way so far.  I did have some 
other thoughts while we were exchanging these messages, though.  Is it possible 
to relax the expectation semantics so that expectations wouldn't have to be set 
*before* the "actuals" happen.  Wouldn't it be more flexible if expectations 
can be set at any time before verification, while actual cases are only 
recorded as they happen?  Then only at verification time they would be compared 
against each other. 

--J.X.

Re: [MO-java-users] any pattern for this?

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

J. Xue wrote:
> Yeah, it seems that an adapter is the most viable way so far.  I did have some 
> other thoughts while we were exchanging these messages, though.  Is it possible 
> to relax the expectation semantics so that expectations wouldn't have to be set 
> *before* the "actuals" happen.  Wouldn't it be more flexible if expectations 
> can be set at any time before verification, while actual cases are only 
> recorded as they happen?  Then only at verification time they would be compared 
> against each other. 

Of course you can do that, but that's a different technique. How much 
this matters depends on your task, what you should be avoiding is the 
sort of test that fails at the end but you can't quite see where, so you 
have to step it through in the debugger. An advantage of MO tests is 
that they fail when the error occurs.

There are also interesting questions about how the test drives the code. 
MO tend to push you towards defining types that talk about the 
relationshps between objects, state tests push you towards exposing 
state in your objects. Your call...

S.

-- 
"A LISP programmer knows the value of everything but the cost of nothing.
  A C programmer knows the cost of everything but the value of nothing."
(Todd Proebsting)

Re: [MO-java-users] any pattern for this?

[J. X. <sou...@ma...>]

Quoting Steve Freeman <st...@m3...>:

> Of course you can do that, but that's a different technique. How much 
> this matters depends on your task, what you should be avoiding is the 
> sort of test that fails at the end but you can't quite see where, so you 
> have to step it through in the debugger. An advantage of MO tests is 
> that they fail when the error occurs.

You (and Nat as he pointed out the same) definitly have a good point.

> There are also interesting questions about how the test drives the code. 
> MO tend to push you towards defining types that talk about the 
> relationshps between objects, state tests push you towards exposing 
> state in your objects. Your call...

That sure is thought-provoking. One thing I have kept pondering on is *how 
much* I would like (or, rather, can afford) the test to drive the code. e.g., 
in this case, my code has had some strong assumption on the usage of castor. 
Would it then still be architecturally reasonable and natural to introduce an 
adapter that essentially duplicates the castor unmarshaller interface for the 
sole purpose of plugging in MO's?

--J.X.

Re: [MO-java-users] any pattern for this?

[Nat P. <nat...@b1...>]

On Wed, 2003-12-17 at 23:02, J. Xue wrote:
> my code has had some strong assumption on the usage of castor. 
> Would it then still be architecturally reasonable and natural to introduce an 
> adapter that essentially duplicates the castor unmarshaller interface for the 
> sole purpose of plugging in MO's?

Your object should make use of interfaces that make sense to it, not
that are defined by technology that you have chosen.  This is what mock
objects are good for: in TDD they drive the design of an object's
*required* interfaces.

Your object needs to unmarshall some data from some input stream.  The
interface should express that.  An implementation of the interface can
use the castor API.  But if you drive the design of the interface from
the needs of your object, not from your choice of castor, then it will
be easy to change your choice of XML API later if you want.  Using mock
objects to drive the design of the interactions between your objects
will naturally lead to such "flex points" in your design.

Cheers,
	Nat.

Re: [MO-java-users] any pattern for this?

[J. X. <sou...@ma...>]

Quoting Nat Pryce <nat...@b1...>:

> Your object should make use of interfaces that make sense to it, not
> that are defined by technology that you have chosen.  This is what mock
> objects are good for: in TDD they drive the design of an object's
> *required* interfaces.

Sometimes, it does make sense to define an abstract interface between a client 
and its vendor, but not all the time, especially when the usage of the vendor 
requires strong assumptions.  In this castor case, castor's (rather intrusive) 
usage paradigm has made a lot of impact on my code, e.g., all the classes 
handled by the marshalling engine must have either public getters/setters or 
have their own castor-dependent handlers.  Another example is that I had to 
make special wrapper classes simply because the XML unmarshaller cannot 
effectively unmarshal a map.  From the design point of view, it would be just 
illusional to have an "un/marshaller interface" and pretend to have the ability 
to "plug in" another un/marshaller.

Well, my question is, then, do mock objects drive, or do they actually *force* 
the design? Following this pattern, wouldn't I have to define interfaces for 
every 3rd party class I use that does not support a factory, in order to be 
able to plug in my own mocked version of those classes?

--J.X.

> 
> Your object needs to unmarshall some data from some input stream.  The
> interface should express that.  An implementation of the interface can
> use the castor API.  But if you drive the design of the interface from
> the needs of your object, not from your choice of castor, then it will
> be easy to change your choice of XML API later if you want.  Using mock
> objects to drive the design of the interactions between your objects
> will naturally lead to such "flex points" in your design.
> 
> Cheers,
> 	Nat.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> 

Re: [MO-java-users] any pattern for this?

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

J. Xue wrote:
> Sometimes, it does make sense to define an abstract interface between
> a client and its vendor, but not all the time, especially when the
> usage of the vendor requires strong assumptions.  In this castor
> case, castor's (rather intrusive) usage paradigm has made a lot of
> impact on my code, e.g., all the classes handled by the marshalling
> engine must have either public getters/setters or have their own
> castor-dependent handlers.  Another example is that I had to make
> special wrapper classes simply because the XML unmarshaller cannot 
> effectively unmarshal a map.  From the design point of view, it would
> be just illusional to have an "un/marshaller interface" and pretend
> to have the ability to "plug in" another un/marshaller.

that's true, I think we were talking about a higher level interface that
has meaning in your domain. It might even be worth distinguishing
between "Castor" objects which are wrapped by "domain" objects.
Actually, that's not a bad idea given that the Castor objects have this
marhshalling baggage. Alternatively, you might want to have some kind of
common factory object that gets passed around and wraps the castor
infrastructure.

> Well, my question is, then, do mock objects drive, or do they
> actually *force* the design? Following this pattern, wouldn't I have
> to define interfaces for every 3rd party class I use that does not
> support a factory, in order to be able to plug in my own mocked
> version of those classes?

See above, maybe there's a thin veneer that converts between state 
(managed by Castor) and behaviour (which is yours).

S.

Re: [MO-java-users] any pattern for this?

[Nat P. <nat...@b1...>]

It is possible to do that in the current (non-dynamic) API.  Just turn
off immediate verification on your expectation objects.

But do you really want to?  It's much harder to work out what went wrong
after the fact because all the state that existed when the error
occurred has been lost.  If the mock fails as soon as it detects an
error it can generate better error messages and you can make the
debugger break into the program when it fails, so letting you examine
your live objects to find the error.

Cheers,
	Nat.



On Wed, 2003-12-17 at 16:37, J. Xue wrote:
> Quoting Nat Pryce <nat...@b1...>:
> 
> > ClassUnderTest would call an interface to perform unmarshalling.  It
> > wouldn't care if the implementation of the interface was an adapter or a
> > direct implementation.  Whichever approach you take (adapter or mocking
> > castor), you'd put the mock unmarshaller into your own test package. 
> > There's no need to touch the castor packages.
> 
> Yeah, it seems that an adapter is the most viable way so far.  I did have some 
> other thoughts while we were exchanging these messages, though.  Is it possible 
> to relax the expectation semantics so that expectations wouldn't have to be set 
> *before* the "actuals" happen.  Wouldn't it be more flexible if expectations 
> can be set at any time before verification, while actual cases are only 
> recorded as they happen?  Then only at verification time they would be compared 
> against each other. 
> 
> --J.X.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

Re: [MO-java-users] any pattern for this?

[J. X. <sou...@ma...>]

Quoting Nat Pryce <nat...@b1...>:

> It is possible to do that in the current (non-dynamic) API.  Just turn
> off immediate verification on your expectation objects.

Are you referring to setFailOnVerify()?  I read through the javadoc, which 
seems to suggest that setFailOnVerify only defers the reporting of failures but 
not verification itself.

Thanks.
--J.X.