Comparing Arrays with Assert.assertEquals in Junit 4.1

[putnam_david_t]

I see that Junit 4.1 has a new method for comparing arrays. However
in my case the arrays are created via reflection. So the arrays are
declared as Object and the Object version of assertEquals does not
examine the array elements. I suggested on the Junit issue tracker
that the Object version of assertEquals be ammended to check if the
two Objects are both arrays then act like the array version.

I am posting this here to see what other discussion this might generate.

Looking forward to hearing from you.

Thanks,
David







Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Lasse Koskela]

[...] I suggested on the Junit issue tracker that the Object version
of assertEquals be ammended to check if the two Objects are
both arrays then act like the array version.

Dave, you read my mind. I was just thinking about this exact thing
last night on the train.

-Lasse-



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Jason Rogers]

That seems to make sense. Two arrays will never be equal objects if they
aren¹t the same object. So, it would make sense to compare their contents.
I tend to discourage RTTI, but in this case I don¹t think it¹s a bad idea.

My $0.02...

Jason

Post by putnam_david_t
I see that Junit 4.1 has a new method for comparing arrays. However
in my case the arrays are created via reflection. So the arrays are
declared as Object and the Object version of assertEquals does not
examine the array elements. I suggested on the Junit issue tracker
that the Object version of assertEquals be ammended to check if the
two Objects are both arrays then act like the array version.
I am posting this here to see what other discussion this might generate.
Looking forward to hearing from you.
Thanks,
David

[Non-text portions of this message have been removed]




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[David Saff]

I have some preference for the current definition. Imagine this test:

Object a = someReflectiveCall("abc");
Object b = someOtherReflectiveCall("cba");
assertEquals(a, b);

To me, this asserts that a and b, whatever they are, are equal according
to Java's definition of equal. This involves all sorts of weirdness
that we might wish weren't so--if a and b are StringBuffers with
identical contents, they will not be equal, and likewise if they are
arrays with identical contents.

If I know that a and b are arrays, then writing

assertEquals((Object[])a, (Object[])b);

is not very burdensome, and has benefits in documenting the behavior of
the tested methods. Does that make sense?

David Saff

Post by Jason Rogers
That seems to make sense. Two arrays will never be equal objects if they
aren¹t the same object. So, it would make sense to compare their contents.
I tend to discourage RTTI, but in this case I don¹t think it¹s a bad idea.
My $0.02...
Jason

Post by putnam_david_t
I see that Junit 4.1 has a new method for comparing arrays. However
in my case the arrays are created via reflection. So the arrays are
declared as Object and the Object version of assertEquals does not
examine the array elements. I suggested on the Junit issue tracker
that the Object version of assertEquals be ammended to check if the
two Objects are both arrays then act like the array version.
I am posting this here to see what other discussion this might generate.
Looking forward to hearing from you.
Thanks,
David

[Non-text portions of this message have been removed]
Yahoo! Groups Links

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[putnam_david_t]

So the intent of assertEquals(a,b) is to be equivalent to
assertTrue(a.equals(b)).

Post by David Saff
Object a = someReflectiveCall("abc");
Object b = someOtherReflectiveCall("cba");
assertEquals(a, b);
To me, this asserts that a and b, whatever they are, are equal

according

Post by David Saff
to Java's definition of equal. This involves all sorts of weirdness
that we might wish weren't so--if a and b are StringBuffers with
identical contents, they will not be equal, and likewise if they are
arrays with identical contents.
If I know that a and b are arrays, then writing
assertEquals((Object[])a, (Object[])b);
is not very burdensome, and has benefits in documenting the behavior of
the tested methods. Does that make sense?
David Saff

Post by Jason Rogers
That seems to make sense. Two arrays will never be equal objects if they
aren¹t the same object. So, it would make sense to compare their contents.
I tend to discourage RTTI, but in this case I don¹t think it¹s a bad idea.
My $0.02...
Jason

Post by putnam_david_t
I see that Junit 4.1 has a new method for comparing arrays. However
in my case the arrays are created via reflection. So the arrays are
declared as Object and the Object version of assertEquals does not
examine the array elements. I suggested on the Junit issue tracker
that the Object version of assertEquals be ammended to check if the
two Objects are both arrays then act like the array version.
I am posting this here to see what other discussion this might generate.
Looking forward to hearing from you.
Thanks,
David

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Kent Beck]

David,

First, I shouldn't have checked anything in without finishing the
conversation here and checking with my teammates. My mistake.

Second, assertEquals(a, b) was equivalent to assertTrue(a.equals(b))
originally. Then we added the exception for array equality. Perhaps we need
to revert assertEquals() to its original definition and define an
assertPrettyDoggoneSimilar() that does fancy stuff with arrays. I'm in favor
of simple mental models, and the original assertEquals() certainly was
simple and straightforward. I hate to lose that.

To the people who'd like a notion of array equality that is more than what
is provided by equals(), what would you like the assertion called?

Cheers,

Kent Beck
Three Rivers Institute


_____

From: ***@yahoogroups.com [mailto:***@yahoogroups.com] On Behalf Of
putnam_david_t
Sent: Monday, October 02, 2006 8:47 AM
To: ***@yahoogroups.com
Subject: [junit] Re: Comparing Arrays with Assert.assertEquals in Junit 4.1



So the intent of assertEquals(a,b) is to be equivalent to
assertTrue(a.equals(b)).

Post by David Saff
Object a = someReflectiveCall("abc");
Object b = someOtherReflectiveCall("cba");
assertEquals(a, b);
To me, this asserts that a and b, whatever they are, are equal

according

Post by David Saff
to Java's definition of equal. This involves all sorts of weirdness
that we might wish weren't so--if a and b are StringBuffers with
identical contents, they will not be equal, and likewise if they are
arrays with identical contents.
If I know that a and b are arrays, then writing
assertEquals((Object[])a, (Object[])b);
is not very burdensome, and has benefits in documenting the behavior of
the tested methods. Does that make sense?
David Saff

Post by Kent Beck
That seems to make sense. Two arrays will never be equal objects

if they

Post by David Saff

Post by Kent Beck
aren¹t the same object. So, it would make sense to compare their

contents.

Post by David Saff

Post by Kent Beck
I tend to discourage RTTI, but in this case I don¹t think it¹s a bad idea.
My $0.02...
Jason

I see that Junit 4.1 has a new method for comparing arrays. However
in my case the arrays are created via reflection. So the arrays are
declared as Object and the Object version of assertEquals does not
examine the array elements. I suggested on the Junit issue tracker
that the Object version of assertEquals be ammended to check if the
two Objects are both arrays then act like the array version.
I am posting this here to see what other discussion this might generate.
Looking forward to hearing from you.
Thanks,
David

[Non-text portions of this message have been removed]




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Mark Levison]

Post by Kent Beck
To the people who'd like a notion of array equality that is more than what
is provided by equals(), what would you like the assertion called?

How about assertArrayEquals()?
BTW I agree we need a separate method. I believe assertEquals(a, b) was
equivalent to assertTrue(a.equals(b)) is an important thing to able to rely
on/

Cheers
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/


[Non-text portions of this message have been removed]




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Jim Yingst]

To keep the model simple, I would suggest *two* new methods based directly on
existing methods in the Arrays class:

assertArraysEquals(a, b), equivalent to assertTrue(Arrays.equals(a, b))

assertArraysDeepEquals(a, b), equivalent to assertTrue(Arrays.deepEquals(a, b))

When I say "equivalent" I am assuming that the new methods will provide better
error messages in case of failure, probably including a string representation
of both arrays. Or perhaps just the index of the first unequal elements, and
their values. E.g. something like:

"Arrays were not deeply equal; at element 4 expected [foo] but was [bar]"

- Jim Yingst

Post by Mark Levison

Post by Kent Beck
To the people who'd like a notion of array equality that is more than what
is provided by equals(), what would you like the assertion called?

How about assertArrayEquals()?
BTW I agree we need a separate method. I believe assertEquals(a, b) was
equivalent to assertTrue(a.equals(b)) is an important thing to able to rely
on/
Cheers
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/
[Non-text portions of this message have been removed]
Yahoo! Groups Links

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Jason Rogers]

+1 here!

Post by Jim Yingst
To keep the model simple, I would suggest *two* new methods based directly on
assertArraysEquals(a, b), equivalent to assertTrue(Arrays.equals(a, b))
assertArraysDeepEquals(a, b), equivalent to assertTrue(Arrays.deepEquals(a, b))
When I say "equivalent" I am assuming that the new methods will provide better
error messages in case of failure, probably including a string representation
of both arrays. Or perhaps just the index of the first unequal elements, and
"Arrays were not deeply equal; at element 4 expected [foo] but was [bar]"
- Jim Yingst

Post by Mark Levison

Post by Kent Beck
To the people who'd like a notion of array equality that is more than

what

Post by Kent Beck
is provided by equals(), what would you like the assertion called?

How about assertArrayEquals()?
BTW I agree we need a separate method. I believe assertEquals(a, b) was
equivalent to assertTrue(a.equals(b)) is an important thing to able to rely
on/
Cheers
Mark Levison
----------------------------------------------------------
Blog: http://www.notesfromatooluser.com/
[Non-text portions of this message have been removed]
Yahoo! Groups Links

[Non-text portions of this message have been removed]




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[putnam_david_t]

I like this approach. By not overloading the assertEquals it makes it
clear that this is not the same as a.equals(b) and because this is
also grounded in the core java functionality, it is easily understood
by people using "Arrays".

I think that the Assert.assertEquivalent(String message, Object a,
Object b) approach will need more support. For instance different
methods for StringBuffers, Arrays, and "other core objects that we
wish had different equality operators". This approach does
differentiate itself from the .equals confusion and is easily
recursive for Array applications. I think that this approach should
imply the deep comparison.

For assertArraysEquals, the algorithm would be to assertEquals on the
cooresponding elements. For assertArraysDeepEquals, the algorithm
would traverse the Arrays to leaf nodes (Objects that are not Arrays)
before invoking assertEquals. Does that summarize the approach you
suggest. This approach leverages the most from the already implemented
assertEquals functionality, provides the easiest way to create the
explicite messages desired, and is easily explained using core Array
functionality.

I for these reasons I think the preferred approach should be the two
methods suggested for arrays. What do you think?

David

Post by Jason Rogers
+1 here!

Post by Jim Yingst
To keep the model simple, I would suggest *two* new methods based directly on
assertArraysEquals(a, b), equivalent to

assertTrue(Arrays.equals(a, b))

Post by Jason Rogers

Post by Jim Yingst
assertArraysDeepEquals(a, b), equivalent to

assertTrue(Arrays.deepEquals(a,

Post by Jason Rogers

Post by Jim Yingst
b))
When I say "equivalent" I am assuming that the new methods will provide better
error messages in case of failure, probably including a string representation
of both arrays. Or perhaps just the index of the first unequal elements, and
"Arrays were not deeply equal; at element 4 expected [foo] but was [bar]"
- Jim Yingst

Post by Mark Levison

Post by Kent Beck
To the people who'd like a notion of array equality that is more than

what

Post by Kent Beck
is provided by equals(), what would you like the assertion called?

How about assertArrayEquals()?
BTW I agree we need a separate method. I believe

assertEquals(a, b) was

Post by Jason Rogers

Post by Jim Yingst

Post by Mark Levison
equivalent to assertTrue(a.equals(b)) is an important thing to able to rely
on/
Cheers
Mark Levison
----------------------------------------------------------
Blog: http://www.notesfromatooluser.com/

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Joakim Ohlrogge]

I have been toying with an assertEquivalent or rather assertThat(xxx,
is.equivalentTo(xxx)) in rMock.

The scope is a bit bigger like

new Integer(4711) is equivalent to new Long(4711) (although .equals returns
false in this case).
it could also check that a list containing "1", "2", "3" is equivalent to
new String[]{"1", "2", "3"}
which could be elegant:

assertEquivalent(new String[]{"1","2","3"}, actual);

compared to:

assertEquals(Arrays.asList(new String[]{"1","2","3"}), actual);

http://dictionary.reference.com/search?r=2&q=equivalent
Any thoughts on equivalent?

Post by Kent Beck
David,
First, I shouldn't have checked anything in without finishing the
conversation here and checking with my teammates. My mistake.
Second, assertEquals(a, b) was equivalent to assertTrue(a.equals(b))
originally. Then we added the exception for array equality. Perhaps we need
to revert assertEquals() to its original definition and define an
assertPrettyDoggoneSimilar() that does fancy stuff with arrays. I'm in favor
of simple mental models, and the original assertEquals() certainly was
simple and straightforward. I hate to lose that.
To the people who'd like a notion of array equality that is more than what
is provided by equals(), what would you like the assertion called?
Cheers,
Kent Beck
Three Rivers Institute
_____
putnam_david_t
Sent: Monday, October 02, 2006 8:47 AM
Subject: [junit] Re: Comparing Arrays with Assert.assertEquals in Junit 4.1
So the intent of assertEquals(a,b) is to be equivalent to
assertTrue(a.equals(b)).
David Saff

Post by David Saff
Object a = someReflectiveCall("abc");
Object b = someOtherReflectiveCall("cba");
assertEquals(a, b);
To me, this asserts that a and b, whatever they are, are equal

according

Post by David Saff
to Java's definition of equal. This involves all sorts of weirdness
that we might wish weren't so--if a and b are StringBuffers with
identical contents, they will not be equal, and likewise if they are
arrays with identical contents.
If I know that a and b are arrays, then writing
assertEquals((Object[])a, (Object[])b);
is not very burdensome, and has benefits in documenting the behavior of
the tested methods. Does that make sense?
David Saff

Post by Kent Beck
That seems to make sense. Two arrays will never be equal objects

if they

Post by David Saff

Post by Kent Beck
aren¹t the same object. So, it would make sense to compare their

contents.

Post by David Saff

Post by Kent Beck
I tend to discourage RTTI, but in this case I don¹t think it¹s a

bad idea.

Post by David Saff

Post by Kent Beck
My $0.02...
Jason

I see that Junit 4.1 has a new method for comparing arrays. However
in my case the arrays are created via reflection. So the arrays are
declared as Object and the Object version of assertEquals does not
examine the array elements. I suggested on the Junit issue tracker
that the Object version of assertEquals be ammended to check if the
two Objects are both arrays then act like the array version.
I am posting this here to see what other discussion this might

generate.

Post by David Saff

Post by Kent Beck

Looking forward to hearing from you.
Thanks,
David

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Elliotte Harold]

Post by Kent Beck
Second, assertEquals(a, b) was equivalent to assertTrue(a.equals(b))
originally. Then we added the exception for array equality. Perhaps we need
to revert assertEquals() to its original definition and define an
assertPrettyDoggoneSimilar() that does fancy stuff with arrays. I'm in favor
of simple mental models, and the original assertEquals() certainly was
simple and straightforward. I hate to lose that.

The problem here is an ugliness in Java. The equals() method does not do
what people expect for arrays.

The principle of least surprise dictates that when assertEquals() is
handed two non-null arrays it return true if and only if the following
conditions hold:

1. The arrays have the same length.
2. Each component of the each array is equal to the corresponding
component of the other array (as defined by equals() or == for primitive
types)
3. The arrays have the same type.

I'm actually not sure about #3, and there's a potential infinite loop in
#2 if you aren't careful; but I do think this is what people expect to
happen; and I doubt anyone will complain if this is what does happen.
--
Elliotte Rusty Harold ***@metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[J. B. Rainsberger]

Post by Kent Beck

Post by Kent Beck
Second, assertEquals(a, b) was equivalent to assertTrue(a.equals(b))
originally. Then we added the exception for array equality. Perhaps

we need

Post by Kent Beck
to revert assertEquals() to its original definition and define an
assertPrettyDoggoneSimilar() that does fancy stuff with arrays. I'm

in favor

Post by Kent Beck
of simple mental models, and the original assertEquals() certainly was
simple and straightforward. I hate to lose that.

The problem here is an ugliness in Java. The equals() method does not do
what people expect for arrays.
The principle of least surprise dictates that when assertEquals() is
handed two non-null arrays it return true if and only if the following
1. The arrays have the same length.
2. Each component of the each array is equal to the corresponding
component of the other array (as defined by equals() or == for primitive
types)
3. The arrays have the same type.
I'm actually not sure about #3, and there's a potential infinite loop in
#2 if you aren't careful; but I do think this is what people expect to
happen; and I doubt anyone will complain if this is what does happen.

Hm. I think the PLS dictates that assertEquals() be equivalent to
assert(a.equals(b)) with the appropriate guard against a == null.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Elliotte Harold]

Post by J. B. Rainsberger
Hm. I think the PLS dictates that assertEquals() be equivalent to
assert(a.equals(b)) with the appropriate guard against a == null.

I understand your point. My problem is that the equals method in the
Array class violates the PLS. Consequently anything that depends on that
method also violates the PLS. Call it the transitivity of surprise.
--
Elliotte Rusty Harold ***@metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[J. B. Rainsberger]

Post by Elliotte Harold

Post by J. B. Rainsberger
Hm. I think the PLS dictates that assertEquals() be equivalent to
assert(a.equals(b)) with the appropriate guard against a == null.

I understand your point. My problem is that the equals method in the
Array class violates the PLS. Consequently anything that depends on that
method also violates the PLS. Call it the transitivity of surprise.

Indeed: it's surprising either way, but I'm not sure JUnit ought to get
into the business of re-writing the equals() method for core Java types.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Kent Beck]

David, Jason, and all:

Thank you for the suggestion. I have checked in a change to handle this. The
test case is:

@Test public void arraysDeclaredAsObjectAreComparedAsArrays() {

Object a1= new Object[] {"abc"};

Object a2= new Object[] {"abc"};

assertEquals(a1, a2);

}

Let me know if this is what you were looking for.

Regards,

Kent Beck, Three Rivers Institute


_____

From: ***@yahoogroups.com [mailto:***@yahoogroups.com] On Behalf Of
Jason Rogers
Sent: Thursday, September 28, 2006 5:36 AM
To: ***@yahoogroups.com
Subject: Re: [junit] Comparing Arrays with Assert.assertEquals in Junit 4.1



That seems to make sense. Two arrays will never be equal objects if they
aren¹t the same object. So, it would make sense to compare their contents.
I tend to discourage RTTI, but in this case I don¹t think it¹s a bad idea.

My $0.02...

Jason

I see that Junit 4.1 has a new method for comparing arrays. However
in my case the arrays are created via reflection. So the arrays are
declared as Object and the Object version of assertEquals does not
examine the array elements. I suggested on the Junit issue tracker
that the Object version of assertEquals be ammended to check if the
two Objects are both arrays then act like the array version.
I am posting this here to see what other discussion this might generate.
Looking forward to hearing from you.
Thanks,
David

[Non-text portions of this message have been removed]







[Non-text portions of this message have been removed]




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Jason Rogers]

That seems sufficient to me.

Post by Kent Beck
Thank you for the suggestion. I have checked in a change to handle this. The
@Test public void arraysDeclaredAsObjectAreComparedAsArrays() {
Object a1= new Object[] {"abc"};
Object a2= new Object[] {"abc"};
assertEquals(a1, a2);
}
Let me know if this is what you were looking for.
Regards,
Kent Beck, Three Rivers Institute
_____
Jason Rogers
Sent: Thursday, September 28, 2006 5:36 AM
Subject: Re: [junit] Comparing Arrays with Assert.assertEquals in Junit 4.1
That seems to make sense. Two arrays will never be equal objects if they
aren¹t the same object. So, it would make sense to compare their contents.
I tend to discourage RTTI, but in this case I don¹t think it¹s a bad idea.
My $0.02...
Jason

I see that Junit 4.1 has a new method for comparing arrays. However
in my case the arrays are created via reflection. So the arrays are
declared as Object and the Object version of assertEquals does not
examine the array elements. I suggested on the Junit issue tracker
that the Object version of assertEquals be ammended to check if the
two Objects are both arrays then act like the array version.
I am posting this here to see what other discussion this might generate.
Looking forward to hearing from you.
Thanks,
David

[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]




Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[putnam_david_t]

I have inserted the casts and the array comparisons are
working well. *Except* when the array elements are null.

String[] expected = {"7", null, "9",
"0"};
String[] received = testingClass.getManyAttribs();
org.junit.Assert.assertEquals(expected, received);

Causes:
java.lang.NullPointerException
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:144)
...

It looks like the check to see if each element might itself
be an array fails when the element is null. o1.getClass() ->
NPE. Looks like the same style of null checking from the
initial arguments is needed before the recursive call to
assertEquals.

One reason I suggested not casting is that within the
assertEquals(Object, Object) code, you could recursivly invoke
assertEquals(Object, Object) without dealing with the special case
that both elements are also arrays.

David

Thanks,
David

Post by Kent Beck
Thank you for the suggestion. I have checked in a change to handle this. The
@Test public void arraysDeclaredAsObjectAreComparedAsArrays() {
Object a1= new Object[] {"abc"};
Object a2= new Object[] {"abc"};
assertEquals(a1, a2);
}
Let me know if this is what you were looking for.
Regards,
Kent Beck, Three Rivers Institute

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/junit/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/junit/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:junit-***@yahoogroups.com
mailto:junit-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
junit-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/