Многие функции JodaTime оперируют с текущим временным поясом. Это хорошо и для приложения, которое автоматически работает с временем корректно и для разработчика, которому не надо писать эту корректность. Но в юнит-тестах «текущий» временной пояс является неопределённым параметром окружения и может вызывать проблемы.
Например у разработчика, находящегося в зоне UTC+3, такой тест отлично отработает:
1
2
3
4
5
6
7
8
9
|
@Test
public void testDefaultTimezone() {
Instant instant = new Instant(450576000000L);
assertThat(instant
.toDateTime()
.toString("YYYY-MM-dd HH:mm:ss"),
is("1984-04-12 03:00:00"));
}
|
Однако, когда он его загрузит на CI сервер находящийся в зоне UTC+4, тест сломается:
1
2
|
testDefaultTimezone(DateTimeSerializerTest) Time elapsed: 0.301 sec <<< FAILURE!
org.junit.ComparisonFailure: expected:<1984-04-12 0[3]:00:00> but was:<1984-04-12 0[4]:00:00>
|
Чтобы избежать обвинений в сломанном билде, разработчику достаточно будет зафиксировать в тесте временной пояс по умолчанию:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
static private DateTimeZone current;
@BeforeClass
public static void setUpClass() {
current = DateTimeZone.getDefault();
DateTimeZone.setDefault(DateTimeZone.UTC);
}
@AfterClass
public static void tearDownClass() {
DateTimeZone.setDefault(current);
}
@Test
public void testDefaultTimezone() {
Instant instant = new Instant(450576000000L);
assertThat(instant
.toDateTime()
.toString("YYYY-MM-dd HH:mm:ss"),
is("1984-04-12 00:00:00"));
}
|
DateTimeZone.setDefault() меняет временной пояс по умолчанию только для JodaTime объектов, не затрагивая временной пояс всей jvm.