[
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)
