Тестирование правильной обработки часового пояса - PullRequest
6 голосов
/ 25 января 2009

Мы работаем с большими объемами данных, все помечены в UTC (на Java). Между чтением этих данных, сохранением их в базе данных и их повторным выводом получилось, что некоторые данные были отключены на один час в летнее время. Поскольку UTC не имеет понятия перехода на летнее время, это явно было ошибкой в ​​программном обеспечении. Когда это станет известно, это легко исправить.

Однако было бы неплохо иметь некоторые модульные / интеграционные тесты, которые работают независимо от текущей разницы во времени - например, Я хотел бы изменить местный часовой пояс и запускать несколько методов снова и снова в этих разных часовых поясах, чтобы убедиться, что UTC обрабатывается правильно.

Поскольку тесты должны выполняться автоматически и - предпочтительно - в пределах одного Testsuite, мне интересно, как лучше всего проверить правильность поведения. После перезапуска JVM было бы легко изменить локальные настройки, такие как часовой пояс, но запустить его в тестовом наборе не так просто.

Кто-нибудь знает о тестовой среде, библиотеке или шаблоне, поддерживающем этот сценарий? Обычно мы работаем с JUnit, но открыты для добавления другой среды / техники, если она помогает избавиться от подобных проблем. Я полагаю, что это скорее интеграционный, чем модульный тест.

Редактировать : уже есть два очень полезных ответа, но я думаю, что там должно быть больше техник. Есть ли у кого-нибудь авторитетная информация о том, когда и как часто будет вызываться TimeZone.getDefault (см. Комментарии к ответам Джона Скитса)?

Примечание : Несмотря на то, что на этот вопрос есть принятый ответ, я не был полностью уверен, какой ответ принять. Даже с этим признанием я хотел бы видеть больше идей и методов.

Спасибо за ваш вклад!

Ответы [ 3 ]

7 голосов
/ 25 января 2009

Java позволяет вам установить часовой пояс по умолчанию (java.util.TimeZone.setDefault). Я написал тесты прежде, чтобы установить часовой пояс для множества различных опций и проверить, что все еще работает. Но будьте осторожны - если вы распараллеливаете большинство своих модульных тестов, вам нужно сделать их последовательными.

Я предлагаю вам протестировать в некоторых часовых поясах с переходом на летнее время, а в некоторых - без. Использование австралийского часового пояса также хорошо, так как летнее время применяется в противоположное время года к северному полушарию.

6 голосов
/ 25 января 2009

Я бы порекомендовал вам проверить JodaTime , который предоставляет немного сахара для более четкого управления проблемами типа Date / Time / TimeZone в вашем коде.

Мы используем их на всех этапах тестирования и производства, поскольку то, как он повышает собственный API Java для проблем даты и времени, не имеет аналогов. Использование их в тестах прекрасно работает в JUnit

1 голос
/ 06 февраля 2009

Каково мнение о подключении к серверам времени и получении обновлений?

...