headers
Nat Pryce | 1 Jan 2006 19:07
Picon

Re: is JMock a good choice to test Filters?

On 12/31/05, Dale King <dalewking@...> wrote:
> And I think the advice of Only Mock types that you own is pretty poor advice
> and isn't really helpful. The real question is not whether someone else owns
> it but whether they did a good design that allowed for substitution, which
> you usually means did they expose the type as an interface or abstract
> class..

Our intention behind the "Only Mock Types You Own" rule was to
emphasise jMock's use as a design tool. That jMock is meant to be used
like a CRC card session with the computer.

Yes, you can mock a third-party interface but what do you do when you
find that the interface isn't quite right: that it doesn't have the
methods you need or that the names aren't quite right?  You're stuck. 
Mocking third-party interfaces lets you design the object under test
but that's only part of what we found we used jMock for.  More
important, we found, was its help in designing the interactions
*between* objects, but you don't get that help if you cannot change
the interactions themselves.

Also, in my experience, mocking interfaces provided by third-party
libraries leads to gradual breakdown of clean layering and
modularisation. When teams test domain model code by mocking
technology layer interfaces, irrelevant concepts from the underlying
technologies leak into the domain model.  This makes it harder to
understand the domain model and hard to switch technologies further
down the line.

More important than the "Only Mock Types You Own" rule was that we
learned to drive the design of interfaces from the needs of the caller
(Continue reading)

Permalink | Reply | 13 comments |
headers
Stephen Freeman | 2 Jan 2006 05:54
Picon

Re: is JMock a good choice to test Filters?

What Nat said.

Joe Walnes coined the phrase to stop people getting stuck on just the  
testing aspects and the endless arguments about how we end up  
reproducing the implementation.

It's worth (in your copious spare time) writing a sizeable chunk of  
code using this style mercilessly to get a feel of what happens. It's  
quite different from what most people do and it's amazing how things  
suddenly click into place.

The killer in Java land is the "Iterator Sandwich": Hibernate ->  
Logic -> Velocity. It clashes with a Tell, Don't Ask approach to  
coding. Curiously, it was actually easier to apply in ASP.Net.

In the XP community, I suspect that DTSTTCPW is probably worse than  
YAGNI. I've heard multiple explanations from senior people in the  
community, but many people seem to take it as Just Write Some Code  
And Declare It Done.

S.

On 1 Jan 2006, at 18:07, Nat Pryce wrote:
> On 12/31/05, Dale King <dalewking@...> wrote:
>> And I think the advice of Only Mock types that you own is pretty  
>> poor advice
>> and isn't really helpful. The real question is not whether someone  
>> else owns
>> it but whether they did a good design that allowed for  
>> substitution, which
(Continue reading)

Permalink | Reply | 5 comments |
headers
David Saff | 2 Jan 2006 16:59
Picon
Favicon

Re: is JMock a good choice to test Filters?

Stephen Freeman wrote:

> The killer in Java land is the "Iterator Sandwich": Hibernate ->  
> Logic -> Velocity. It clashes with a Tell, Don't Ask approach to  
> coding. Curiously, it was actually easier to apply in ASP.Net.

Stephen,

Can you go into a bit more detail here?  Are you saying that Hibernate 
->  Logic -> Velocity is difficult when you Only Mock Types You Own, or 
easy?  Thanks,

    David Saff
Permalink | Reply | 1 comment |
headers
Stephen Freeman | 2 Jan 2006 18:07
Picon

Re: is JMock a good choice to test Filters?

Sorry. I meant that trying to follow a "Tell, Don't Ask" style (in  
which behaviour is passed around rather than data) feels harder when  
the standard frameworks want to work with collections. The easiest  
thing to do with this combination is to return a List from Hibernate  
to be iterated over in Velocity.

S.

On 2 Jan 2006, at 15:59, David Saff wrote:
> Stephen Freeman wrote:
>
>> The killer in Java land is the "Iterator Sandwich": Hibernate ->   
>> Logic -> Velocity. It clashes with a Tell, Don't Ask approach to   
>> coding. Curiously, it was actually easier to apply in ASP.Net.
>
> Stephen,
>
> Can you go into a bit more detail here?  Are you saying that  
> Hibernate ->  Logic -> Velocity is difficult when you Only Mock  
> Types You Own, or easy?  Thanks,
>
>    David Saff
>
Permalink | Reply | 0 comments |
headers
Ariel Valentin | 5 Jan 2006 16:07
Picon
Favicon

Nested Arrays Comparison Problem

I have run into an issue when attemping to compare maps that contain arrays. 
I set my expectations, but an invocation error is thrown. Is this because 
the array object's .equals() method compares the array object reference and 
not the items it contains?

for example:
Map m = new HashMap();

Y y = new Y[7]; //Y's equals method is implemented.
//... yada yada

m.put("y", y)
x.expects(once()).method("setMap").with(eq(map));

Thanks,

Mr. Ariel S. Valentin
Permalink | Reply | 9 comments |
headers
David Jackman | 5 Jan 2006 18:01

RE: Nested Arrays Comparison Problem

You probably need to write your own Constraint class that handles this
for you.  I wrote my own MapEquals constraint for testing that maps are
equal (not leaving it up to a particular implementation of equals()).
You may have to extend my implementation further to work with map values
that are arrays.  Here's what your code would look like using my
constraint:

Map map = new HashMap();
Y y = new Y[7]; //Y's equals method is implemented.
//... yada yada
map.put("y", y)
x.expects(once()).method("setMap").with(new MapEquals(map));

Here is my MapEquals class:

/**
 * Constrains an object to be a map that equals another map.
 * 
 *  <at> author DJackman
 */
public class MapEquals implements Constraint
{
    private final Map m_expectedMap;

    
    /**
     * Initializes a new instance of this class.
     * 
     *  <at> param expectedMap  expected map.
     */
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jörg Schaible | 5 Jan 2006 22:32
Picon
Picon
Gravatar

Re: Nested Arrays Comparison Problem

Hi Ariel,

Ariel Valentin wrote:

> I have run into an issue when attemping to compare maps that contain
> arrays. I set my expectations, but an invocation error is thrown. Is this
> because the array object's .equals() method compares the array object
> reference and not the items it contains?
> 
> for example:
> Map m = new HashMap();
> 
> Y y = new Y[7]; //Y's equals method is implemented.
> //... yada yada

Did you also overload hashCode() ? Note, that "equal" objects should have an
equal hashCode ...

> 
> m.put("y", y)
> x.expects(once()).method("setMap").with(eq(map));
> 
> Thanks,
> 
> Mr. Ariel S. Valentin

- Jörg
Permalink | Reply | 1 comment |
headers
J. B. Rainsberger | 6 Jan 2006 01:35
Favicon

Re: is JMock a good choice to test Filters?

Stephen Freeman wrote:
> What Nat said.
> 
> Joe Walnes coined the phrase to stop people getting stuck on just the 
> testing aspects and the endless arguments about how we end up 
> reproducing the implementation.
> 
> It's worth (in your copious spare time) writing a sizeable chunk of code 
> using this style mercilessly to get a feel of what happens. It's quite 
> different from what most people do and it's amazing how things suddenly 
> click into place.

I had to write an entire J2EE application from scratch with no outside 
frameworks to really get a feel for how this approach affects my 
designs. I don't recommend doing this for paid work unless you have 
mastered your relationship with your boss/client, but it worked for me.
--

-- 
J. B. (Joe) Rainsberger :: http://www.jbrains.info
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice
Permalink | Reply | 2 comments |
headers
J. B. Rainsberger | 6 Jan 2006 01:39
Favicon

Re: Nested Arrays Comparison Problem

Ariel Valentin wrote:
> I have run into an issue when attemping to compare maps that contain 
> arrays. I set my expectations, but an invocation error is thrown. Is 
> this because the array object's .equals() method compares the array 
> object reference and not the items it contains?
> 
> for example:
> Map m = new HashMap();
> 
> Y y = new Y[7]; //Y's equals method is implemented.
> //... yada yada
> 
> m.put("y", y)
> x.expects(once()).method("setMap").with(eq(map));

It's exactly because arrays don't define equals() to check element-wise.

For a quick fix, wrap the array in a list and you'll get the right 
equals() behavior:

m.put("y", Arrays.asList(y));

For perhaps a better fix, create your own eq() Constraint that does the 
wrapping for you. I generally dislike arrays and typically wrap them in 
lists as a matter of course, but I recognize that not everyone likes to 
do that.

Take care.
--

-- 
J. B. (Joe) Rainsberger :: http://www.jbrains.info
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ariel Valentin | 6 Jan 2006 06:06
Picon
Favicon

RE: Nested Arrays Comparison Problem

I have decided use a List instead of an array, I will however make an 
attempt a little later to follow up on David's suggestion.

Thanks again,

Mr. Ariel S. Valentin

>From: "David Jackman" <David.Jackman@...>
>Reply-To: user@...
>To: <user@...>
>Subject: RE: [jmock-user] Nested Arrays Comparison Problem
>Date: Thu, 5 Jan 2006 10:01:13 -0700
>
>You probably need to write your own Constraint class that handles this
>for you.  I wrote my own MapEquals constraint for testing that maps are
>equal (not leaving it up to a particular implementation of equals()).
>You may have to extend my implementation further to work with map values
>that are arrays.  Here's what your code would look like using my
>constraint:
>
>Map map = new HashMap();
>Y y = new Y[7]; //Y's equals method is implemented.
>//... yada yada
>map.put("y", y)
>x.expects(once()).method("setMap").with(new MapEquals(map));
>
>
>Here is my MapEquals class:
>
>/**
(Continue reading)

Permalink | Reply | 0 comments |

Gmane