Prev: JDK 1.5.0_21 released
Next: LWUIT and J2ME
From: Lew on 9 Sep 2009 14:14
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

From: Mike Schilling on 9 Sep 2009 15:34
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.


From: Roedy Green on 9 Sep 2009 16:18
On Wed, 9 Sep 2009 09:28:31 -0700 (PDT), grz01 <grz01(a)spray.se> 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.
From: Patricia Shanahan on 9 Sep 2009 16:41
grz01 wrote:
....
> Integer i = ...;
> Long l = ...;
> assertEquals(i,(Integer)l.intValue);
....

Several people have indicated that you should be widening the expected
value, i, rather than narrowing the actual value, l. I thought an
example might help show why this matters. testOne passes, but
outputs:

Expected 10
Actual 4294967306

testTwo fails, junit.framework.AssertionFailedError: expected:<10> but
was:<4294967306>

import junit.framework.TestCase;

public class ConversionTest extends TestCase{
Integer expected = new Integer(10);
Long actual = new Long(4294967306L);

public void testOne() {
assertEquals(expected.intValue(), actual.intValue());
System.out.println("Expected "+expected);
System.out.println("Actual "+actual);
}

public void testTwo() {
assertEquals(expected.longValue(), actual.longValue());
}
}

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. Testing for
equality to the result of widening the expected value does that along
with checking the low order bits of the value. Narrowing the actual
value does not.

I would agree with the narrowing test if, and only if, the value of
actual were specified as something like "Any Long whose value's
conversion to int is ...".

Patricia
From: Arne Vajhøj on 9 Sep 2009 18:39
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




First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9
Prev: JDK 1.5.0_21 released
Next: LWUIT and J2ME