Подтвердить что ты не робот

Можно ли использовать DateTimeUtils.setCurrentMillisFixed в тестах?

Чтобы проверить временный код, полезно использовать шаблон виртуальных часов

Идея состоит в том, что мы вытягиваем текущее время, не используя new Date, а из часов, которые можно высмеять с помощью виртуальных часов, возвращающих предопределенное фиксированное время.

Теперь в Java есть JodaTime с классом DateTime и который позволяет установить время выборки с помощью

DateTimeUtils.setCurrentMillisFixed(today.getMillis());

И reset фиксированное время для системного времени с помощью:

DateTimeUtils.setCurrentMillisSystem();

Вот хорошая статья о том, как использовать его с TestNG.

Теперь вопрос!

Насколько безопасно использовать этот метод с помощью методов setUp и tearDown, если он глобально устанавливает фиксированное время в глобальном контексте на время выполнения теста. Пока я получаю это - он будет работать только до тех пор, пока у нас не будет двух параллельных тестов, когда этот метод будет работать в одной и той же среде параллельно.

4b9b3361

ОТВЕТЫ

Ответ 1

Вы должны убедиться, что DateTimeUtils.setCurrentMillisSystem() вызывается в методе tearDown. Так что один тест не влияет на другого. TestNG должен вызывать tearDown, даже если в вашем тесте возникает исключение.

Я часто предпочитаю другой способ, когда хочу отделить класс от System.currentTimeMillis();. Я представляю интерфейс Clock и одну реализацию SystemClock следующим образом:

public interface Clock {
    public long getCurrentTimeMillis();
}

public class SystemClock implements Clock {
    public long getCurrentTimeMillis(){
        return System.currentTimeMillis();
    }
}

Для тестов тогда легко создать макет, который либо возвращает фиксированное время для каждого вызова, либо из серии предопределенных времен.

Некоторые могут утверждать, что чрезмерная инженерия вводит такой интерфейс, чтобы отделить только один метод, и это повлияет на производительность. Но, к счастью, у нас есть JIT-компилятор, и поскольку JIT знает, что загружен только класс SystemClock, он знает, что никакой другой реализации не существует (на данный момент). В этом предположении он может просто использовать встроенный метод.

Поэтому я предпочитаю писать код так, как он может быть лучше всего проверен.