Integer / Long comparison

[Pitch]

Hi
In JUnit I want to compare an Integer with a Long, as 2 Integers --
say like this:

Integer i = ...;
Long l = ...;
assertEquals(i,l); // assertEquals is ambigous, doesnt work

Maybe you should redesign the code so they are the same type.

 

[Lew]

grz01 says...

Maybe you should redesign the code so they are the same type.

grz01 already told us two days ago:

 

[Morris Keesan]

Maybe you should redesign the code so they are the same type.

or simply sidestep the issue by replacing the assertEquals with
assertTrue(i == l);

 

[markspace]

or simply sidestep the issue by replacing the assertEquals with
assertTrue(i == l);

Will that work if i and l are objects instead of primitives, as has
already been indicated?

Also, I like to use assertEquals if possible, because it provides more
information on a failure.

 

[Lew]

grz01 says...

or simply sidestep the issue by replacing the assertEquals with
    assertTrue(i == l);

That will always fail since it will always be true that 'eye != ell'.

(I changed the variable names from 'i' to 'eye' and from 'l' to 'ell'
for readability because 'l' looks too much like '1'.)

 

[John B. Matthews]

grz01 says...



That will always fail since it will always be true that 'eye != ell'.

That was my first thought, but the compiler sees they are "incomparable
types." Casting to the abstract superclass fails as expected:

Assert.assertTrue((Number)eye == (Number)ell);

(I changed the variable names from 'i' to 'eye' and from 'l' to 'ell'
for readability because 'l' looks too much like '1'.)

Agreed.

 

[Lew]

That was my first thought, but the compiler sees they are "incomparable
types."

That, too, is failure, of a different kind.

Casting to the abstract superclass fails as expected:
Assert.assertTrue((Number)eye == (Number)ell);

Either way, direct comparison of the object references via '==' is not
the right approach.

 

[markspace]

That was my first thought, but the compiler sees they are "incomparable
types." Casting to the abstract superclass fails as expected:

I had no idea the compiler would spot that. Thanks for point this out!

 

[Pitch]

grz01 says...


grz01 already told us two days ago:

So if both types are from a third party, there is nothing he can do
about the performance, but read the documentation and choose what's the
best aproach to keep data integrity.

 

[Lew]

So if both types are from a third party, there is nothing he can do
about the performance, but read the documentation and choose what's the
best aproach to keep data integrity.

There isn't a performance issue here in the first place.

Since the types are from a third party, there's nothing the OP can do
about that choice regardless of whether it's a performance,
productivity or integrity issue, but work with the types given him.

 

[Mike Schilling]

There isn't a performance issue here in the first place.

Since the types are from a third party, there's nothing the OP can
do
about that choice regardless of whether it's a performance,
productivity or integrity issue, but work with the types given him.

The simplest way to do this, I suspect, is to

1. subclass TestCase.(to, say, TestCaseWithBloodyStupidBoxedTypes)
2. implement all needed assertEquals() overloads in this subclass
3. derive all the unit tests from the subclass

Now, when a test calls assertEquals(Boolean, Quaternion), it'll find
an exact match.

 

[markspace]

Now, when a test calls assertEquals(Boolean, Quaternion), it'll find
an exact match.

I think the OP could just make one assertEquals( Object, Object )
method, and call the toString of each object. Then compare based on the
strings.

 

[Lew]

I think the OP could just make one assertEquals( Object, Object )
method, and call the toString of each object. Then compare based on the
strings.

Given his attention to micro-optimization upthread, he might prefer Patricia's
recommendation to use longValue() on the Integer and Long arguments.

Given the simplicity of the longValue() approach, I know I prefer it.

 

[markspace]

There would be no need to create a new assertEquals. Junit's
assertEquals already handles two String arguments.

I was trying to be facetious. Declare an argument type of Object, and
with auto-boxing one loses all control of type. "Object" will literally
accept any type of argument at all. Type troubles will go away, but
like weakly typed languages like PHP, you might find other troubles
surface later.

It is not a general solution, because there is no general guarantee that
actual.toString() gives a different result from expected.toString() in
all failure cases.

Like this one.

 

[Pitch]

There isn't a performance issue here in the first place.

I thought he was talking about micro-optimizations and avoiding two
conversions.

 

[Lew]

I thought he was talking about micro-optimizations and avoiding two
conversions.

There weren't two conversions, only one. The one is a widening from int to
long, hardly expensive enough to constitute a performance issue. All Hotpost
would have to do is load the int into a 64=bit register and the conversion is
essentially free. There isn't a performance issue here in the first place.

 

[Mike Schilling]

There weren't two conversions, only one. The one is a widening from
int to long, hardly expensive enough to constitute a performance
issue. All Hotpost would have to do is load the int into a 64=bit
register and the conversion is essentially free. There isn't a
performance issue here in the first place.

These are unit tests, and the assertEquals call is to verify the
correctness of some presmably non-trivial operation. There wouldn't
be a performance issue even if there were 12 conversions.

 

[Morris Keesan]

Will that work if i and l are objects instead of primitives, as has
already been indicated?

No. My apologies. I've been dealing with too many different languages,
and I lose track. I was thinking of
assertTrue(i.equals(l)), or assertTrue(l.equals(i))
but looking at the documentation I see that those won't work either,
because Integer.equals() never returns true if its parameter isn't an
Integer, and similarly for Long.equals(), so never mind.