commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: [lang] nightly build failed.
Date Mon, 21 Aug 2006 10:18:15 GMT
Hi Henry,

Henri Yandell wrote on Monday, August 21, 2006 8:29 AM:

> On 14 Aug 2006 13:05:53 -0000, psteitz@apache.org
> <psteitz@apache.org> wrote:
>> Failed build logs:
>> http://people.apache.org/~psteitz/commons-nightlies/20060814/io.log
>> 
> http://people.apache.org/~psteitz/commons-nightlies/20060814/lang.log
> 
> Interesting error.
> 
> Testcase:
> testBugzilla38401(org.apache.commons.lang.time.DurationFormatU
> tilsTest):	FAILED expected:<...0> but was:<...1>
> junit.framework.ComparisonFailure: expected:<...0> but was:<...1> 	at
> org.apache.commons.lang.time.DurationFormatUtilsTest.testBugzi
> lla38401(DurationFormatUtilsTest.java:408)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 	at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> 	orImpl.java:39) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> odAccessorImpl.java:25) 
> 
> It's not the same failure as the code had before that bug was fixed;
> and we've only seen it the once so far over the period of nightly
> builds. Always a pain that JUnit doesn't output the expected and was
> text fully (when it's a small amount of text anyway).
> 
> The expected text is:  "0000/00/30 16:00:00 000". That being the
> difference between the following lines:
> 
>         cal1.set(2006, 0, 26, 18, 47, 34);
>         cal2.set(2006, 1, 26, 10, 47, 34);
> 
> I've no idea as to where a '1' might creep in for one of the '0's.

Have a second look at the JUnit ouput and you'll see, that it is the last digit we're talking
about. And the case is easy, the test code does not set the millis and it assumes, that the
call to set is within the same ms. A call to Calendar.getInstance() will initialize the calendar
with the current time. Since the call is done twice, the system time might have been changed.
With the OS shifting time, it is much more likely to happen.

To fix the test, just set the millis to 0 (i.e. call setImeInMillis(0) before setting the
other values).

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message