jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: failing timeshift test
Date Sun, 08 Mar 2020 16:31:14 GMT

Am 08.03.20 um 13:56 schrieb Felix Schumacher:
> Am 08.03.20 um 13:53 schrieb Vladimir Sitnikov:
>>> interpretation of LocalTime addition operations and parsing
>> Well, the function itself does a lot of time parsing, so I am nowhere sure
>> if it contains bug or not.
>> Did you mean the test fails at the specific date only?
> Yes, my thinking was that it started to fail 10 days before dst switch
> (in new york), but I am not sure anymore, that that was really the cause.

So, now I have set up a test vm with date set to 2020-03-04 and a
TZ=America/New_York.

Running the build step will fail reliable with

FAILURE   0.3sec, org.apache.jmeter.functions.TestTimeShiftFunction >
testNowWithComplexPeriod()
    java.lang.AssertionError:
    Expected: the date is within 1 seconds of Fri, 13 Mar 2020
06:27:44.409 PM
         but: the date is Fri, 13 Mar 2020 07:27:44.000 PM and 3599
seconds different
        at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
        at org.junit.Assert.assertThat(Assert.java:964)
        at org.junit.Assert.assertThat(Assert.java:930)
        at
org.apache.jmeter.functions.TestTimeShiftFunction.testNowWithComplexPeriod(TestTimeShiftFunction.java:116)

FAILURE   0.4sec,   12 completed,   1 failed,   0 skipped,
org.apache.jmeter.functions.TestTimeShiftFunction

If I add the DST offset between those dates (Mar-04 and Mar-13) by using
something like

+    private int dstOffset(Date from, Date to) {
+        Calendar cal = Calendar.getInstance(); // use the locale and
timezone of the current machine
+        cal.setTime(from);
+        int fromOffset = cal.get(Calendar.DST_OFFSET);
+        cal.setTime(to);
+        int toOffset = cal.get(Calendar.DST_OFFSET);
+        if (fromOffset == toOffset) {
+            return 0;
+        }
+        return (fromOffset - toOffset) / 1000;
+    }

the failure is fixed. So I believe that my first idea was correct.

Felix

>> However, the concurrent execution of tests that alter timezone is not
>> something we intended to do.
>> Technically speaking, JUnit5 has ResourceLock notation (see
>> https://github.com/junit-team/junit5/issues/2142#issuecomment-596199239 )
> Right, that is something we didn't intend to do.
>
> Felix
>
>> Vladimir
>>

Mime
View raw message