commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilguiz Latypov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IO-476) FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date
Date Wed, 15 Apr 2015 21:02:01 GMT

     [ https://issues.apache.org/jira/browse/IO-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ilguiz Latypov updated IO-476:
------------------------------
    Description: 
The test "FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date" failed in a
nightly run of our tests that needed an arbitrary project such as Apache's Commons IO to work
against.

I suspect that the failure resulted from a system time adjustment taking place between the
instantiation of the Date() object and creating a "new" file where its time stamp has to differ
from one of a "reference" file,

https://github.com/apache/commons-io/blob/8ba672075d917ecb4da15e023bd3dcb47905d7a1/src/test/java/org/apache/commons/io/FileUtilsTestCase.java#L987

Since system time lacks guaranteed continuity, the tests could stabilize by dropping the use
of the current time and stopping the assumption that any unequal time stamp as the code progresses
turns larger than the one we compare against.

(a) The tests against the current time stamps created with Date() could stabilize by making
sure that these time stamps grew larger than the reference stamp and by making sure that every
subsequent file stamp and system time reading has a value larger than before.

(b) The wait for unequal time stamps could stabilize by waiting for the stamp value that outgrows
the reference one.

This will make the tests all the more trivial and less useful.  Having a guaranteed continuous
time source could make them substantial. Not sure if JVM's re-ordering the instructions could
de-stabilize tests that connect to the file system and the desired continuous time source.


  was:
The test "FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date" failed in a
nightly run of our tests that needed an arbitrary project such as Apache's Commons IO to work
against.

I suspect that the failure resulted from a system time adjustment taking place between the
instantiation of the Date() object and creating a "new" file where its time stamp has to differ
from one of a "reference" file,

https://github.com/apache/commons-io/blob/8ba672075d917ecb4da15e023bd3dcb47905d7a1/src/test/java/org/apache/commons/io/FileUtilsTestCase.java#L987

Since system time lacks guaranteed continuity, the tests could stabilize by dropping the use
of the current time and stopping the assumption that any unequal time stamp as the code progresses
turns larger than the one we compare against.

(a) The tests against the current time stamps created with Date() could stabilize by making
sure that these time stamps grew larger than the reference stamp and by making sure that every
subsequent file stamp and system time reading has a value larger than before.

(b) The wait for unequal time stamps could stabilize by waiting for the stamp value that outgrows
the reference one.

This will make the tests all the more trivial and less useful.  Having a guaranteed continuous
time source could make them substantial.



> FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date
> ------------------------------------------------------------------
>
>                 Key: IO-476
>                 URL: https://issues.apache.org/jira/browse/IO-476
>             Project: Commons IO
>          Issue Type: Test
>            Reporter: Ilguiz Latypov
>            Priority: Minor
>              Labels: test
>
> The test "FileUtilsTestCase.testIsFileNewerOlder:987 New File - Newer - Date" failed
in a nightly run of our tests that needed an arbitrary project such as Apache's Commons IO
to work against.
> I suspect that the failure resulted from a system time adjustment taking place between
the instantiation of the Date() object and creating a "new" file where its time stamp has
to differ from one of a "reference" file,
> https://github.com/apache/commons-io/blob/8ba672075d917ecb4da15e023bd3dcb47905d7a1/src/test/java/org/apache/commons/io/FileUtilsTestCase.java#L987
> Since system time lacks guaranteed continuity, the tests could stabilize by dropping
the use of the current time and stopping the assumption that any unequal time stamp as the
code progresses turns larger than the one we compare against.
> (a) The tests against the current time stamps created with Date() could stabilize by
making sure that these time stamps grew larger than the reference stamp and by making sure
that every subsequent file stamp and system time reading has a value larger than before.
> (b) The wait for unequal time stamps could stabilize by waiting for the stamp value that
outgrows the reference one.
> This will make the tests all the more trivial and less useful.  Having a guaranteed continuous
time source could make them substantial. Not sure if JVM's re-ordering the instructions could
de-stabilize tests that connect to the file system and the desired continuous time source.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message