Безопасно ли вызывать TimeZone.setDefault в методе @Before в JUnit? - PullRequest
0 голосов
/ 28 октября 2018

Здесь - комментарий о настройке часового пояса по умолчанию для тестового кода в методе @Before теста JUnit.Но TimeZone.setDefault - это статический метод.Может ли это повлиять на другой тест, который запускается после теста с @Before и TimeZone.setDefault завершение успешно?

Ответы [ 2 ]

0 голосов
/ 29 октября 2018

Здесь есть много вещей, которые нужно проверить, это зависит от того, как вы запускаете тесты.

Могут учитываться следующие факторы:

  1. Поскольку вы пометили «maven» в вопросе: надежные / отказоустойчивые плагины Maven, отвечающие за запуск тестов, могут одновременно запускать несколько тестов в одной или нескольких JVM, все зависит от их конфигурации. Таким образом, тесты могут периодически давать сбои во время сборки, даже если они проходят локально.

  2. @Before и @After вызываются до и после каждого теста в тестовом примере соответственно. @After вызывается, даже если тест не пройден. Так что, вероятно, запоминание часового пояса по умолчанию и его установка после теста должны быть в порядке, но не «переустановка» состояния в блоке «@After» может привести к неправильным определениям в последующих тестах.

Лучшим подходом ИМХО является использование java.time.Clock абстракции. См. этот вопрос для примеров

Другой возможный вариант - рефакторинг кода для использования некоторой «фабрики» для предоставления текущей даты / времени. Затем в модульном тесте вы можете создать экземпляр этой фабрики и «внедрить» ее в качестве зависимости в тестируемый код. Своего рода часы ручной работы

0 голосов
/ 28 октября 2018

Это повлияет на другие тесты (как вы и предполагали), так как не будет сброшено после выполнения одного теста.Либо сбросьте его в «нормальное» методом @After, либо, возможно, измените код, чтобы взять / ввести метку времени для «сейчас», и заставить код выполнить его оттуда.По моему опыту, это даст вам больше гибкости.

...