«

Correction:

Lew wrote:
> The answer to that question is yes, the conversion of Long to Integer,
> which, BTW, is the wrong direction to convert as you've already been
> told,
is impossible,
> as you can tell by reading the Javadocs.

--
Lew

grz01 wrote:
>> What do you imagine the difficulty to be with the two "conversions"
>> that you imagine happening here?
>>
>> --
>> Lew
>
>
> Hi Lew,
>
> Just like with
>
> assertEquals(good.grief(), (Integer)oh.dear().intValue())
>
> it's not a "difficulty", admittedly. That works, too.
> I just think it would be neater with a single step, esp. when this
> type of code repeats many hundred times in our test-cases.


Then write a method

void assertEquals(String s, Long l, Integer i)
{
assertEquals(s, l.longValue(), i.longValue());
}

And call it as often as you like.

On Wed, 9 Sep 2009 09:28:31 -0700 (PDT), grz01 <> wrote,
quoted or indirectly quoted someone who said :

>
>So just wondered, Is there a direct way to go from Long to Integer,

see http://mindprod.com/applet/converter.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"The coolest thing to do with your data will be thought of by someone else."
~ Rufus Pollock (born: 1978 age: 31) in Talk.

grz01 wrote:
>> What do you imagine the difficulty to be with the two "conversions"
>> that you imagine happening here?
> Just like with
>
> assertEquals(good.grief(), (Integer)oh.dear().intValue())
>
> it's not a "difficulty", admittedly. That works, too.
> I just think it would be neater with a single step, esp. when this
> type of code repeats many hundred times in our test-cases.

Let us say that:
- each instance adds 10 nano seconds to your test run
- your test contains 1000 instances
- your test is run 10000 times
then it "cost" you a total of 1/10th of a second.

Not worth it.

Arne

Patricia Shanahan wrote:
> Even if the value of a Long is supposed to be in the Integer range, a
> unit test should check that it is in range, not assume it.

Very relevant point.

It is not good to check if some code is OK by
assuming that the code is OK.

Arne

Arne Vajhøj wrote:
> Patricia Shanahan wrote:
>> Even if the value of a Long is supposed to be in the Integer range,
>> a
>> unit test should check that it is in range, not assume it.
>
> Very relevant point.
>
> It is not good to check if some code is OK by
> assuming that the code is OK.

I'm also wondering why Longs and Integers insread of longs and ints.
(assertEquals(long, int) would unambiguously call the (long, long)
overload).Without seeing the code it's hard to tell, but I wonder if
it should be using primitives, but autoboxing had made using objects
instead transparent until this cropped up.

Mike Schilling wrote:
> Arne Vajhøj wrote:
>> Patricia Shanahan wrote:
>>> Even if the value of a Long is supposed to be in the Integer range,
>>> a
>>> unit test should check that it is in range, not assume it.
>> Very relevant point.
>>
>> It is not good to check if some code is OK by
>> assuming that the code is OK.
>
> I'm also wondering why Longs and Integers insread of longs and ints.
> (assertEquals(long, int) would unambiguously call the (long, long)
> overload).Without seeing the code it's hard to tell, but I wonder if
> it should be using primitives, but autoboxing had made using objects
> instead transparent until this cropped up.

Maybe they need to be nullable.

But changing them to simple types would absolute help on the problem.

Arne

Mike Schilling wrote:
> I'm also wondering why Longs and Integers insread of longs and ints.
> (assertEquals(long, int) would unambiguously call the (long, long)
> overload).Without seeing the code it's hard to tell, but I wonder if
> it should be using primitives, but autoboxing had made using objects
> instead transparent until this cropped up.

A (Long, Integer) can be passed into a (long, long) method call, so it's
not necessarily the autounboxing per se that's causing the problem.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Joshua Cranmer wrote:
> Mike Schilling wrote:
>> I'm also wondering why Longs and Integers insread of longs and
>> ints.
>> (assertEquals(long, int) would unambiguously call the (long, long)
>> overload).Without seeing the code it's hard to tell, but I wonder
>> if
>> it should be using primitives, but autoboxing had made using
>> objects
>> instead transparent until this cropped up.
>
> A (Long, Integer) can be passed into a (long, long) method call, so
> it's not necessarily the autounboxing per se that's causing the
> problem.

The problem, I suspect, is that assertEquals() has many, many
overloads, and the result is that which one to call is ambiguous .

Patricia Shanahan wrote:

>
> There is a simple approach to assertEquals that always works,
> without
> having to spend time rereading the method selection rules in the
> JLS.
>
> Decide the appropriate type for the comparison. Cast/box/unbox etc.
> to
> force both the expect and actual arguments to be expressions of that
> type. In the OP's case, I think the appropriate type for the
> comparison is long, so I would use the longValue methods to get a
> long from each of i and l.

Unless null is a possible and perhaps expected result. Then it's a
bit more complicated.