В мире существует множество клёвых маленьких библиотек, которые как бы и не знаменитые, но очень полезные. Идея в том, чтобы потихоньку знакомить Хабр с такими вещами под тэгом #javalifehacker. Сегодня речь пойдёт о time-test, в котором всего 16 коммитов, но их хватает. Автор библиотеки — Никита Коваль, и это перевод его статьи, изначально написанной для блога Devexperts.

Бывает непросто написать юнит-тесты для завязанной на работу со временем функциональности. Иногда можно взять метод, возвращающий время, и заменить его реализацию на тестовый код. Но для тестирования реальных приложений этого недостаточно. Давайте разберёмся, почему такое решение может не сработать и что в действительности нужно для тестирования времени.

Вот простейший метод, считающий количество дней до конца света:

fun daysBeforeDoom() {
    return doomTime - System.currentTimeMillis()) / millisInDay
}

Скорее всего, для его тестирования достаточно простой подмены всех вызовов System.currentTimeMillis() с помощью существующих инструментов (раз, два) или написания трансформации кода на ASM или AspectJ (если нужно какое-то специализированное поведение).

Но существуют случаи, когда этого подхода недостаточно. Представьте, что мы пишем будильник, который будит каждый день и отображает сообщение: «Осталось <N> дней до конца света»:

while (true) {
    Thread.sleep(ONE_DAY)
    println("${daysBeforeDoom()} days left till the doomsday")
}

Но как протестировать этот код? Как проверить, что он действительно выполняется каждый день и выводит правильное сообщение? Используя простейший подход из примера выше и подменив System.currentTimeMillis(), можно проверить корректность сообщения и только. Но чтобы протестировать корректность расписания, придётся ждать целый день.

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

Итак, имеется два метода, которые возвращают время: System.currentTimeMillis() и System.nanoTime(). Кроме того, имеется несколько синхронизирующих методов с возможностью указать максимальное время ожидания: Thread.sleep(..), Object.wait(..) и LockSupport.park(..).

Чтобы управлять временем, хочется сделать какой-то метод increaseTime(..), который изменяет виртуальное время и будит необходимые потоки.

Достичь этого можно, если все работающие со временем методы заменить на тестовые реализации. Давайте взглянем, как это могло бы работать.

Пример теста:

increaseTime(ONE_DAY)
checkMessage()

Вы, наверное, уже заметили, что этот тест создаёт потенциальную возможность гонок между проверкой сообщения и операцией печати, которая не выполняется моментально. Конечно, можно попробовать добавить паузу.

increaseTime(ONE_DAY)
Thread.sleep(500 /*ms*/)
checkMessage()

В обычной жизни этот тест почти всегда будет работать, но нет никаких настоящих гарантий, что checkMessage() не вызовется раньше, чем отобразится сообщение. Это может случиться в результате нарастания сложности логики тестирования или просто при запуске кода на перегруженном сервере. Тут может возникнуть желание увеличить таймаут, но это решение только замедлит тесты, а гарантий корректности всё так же не будет.

Вместо этого нам нужен специальный метод, который ждёт, пока все проснувшиеся треды не сделают своё дело.

В идеале хотелось бы написать такой тест:

increaseTime(ONE_DAY)
waitUntilThreadsAreFrozen(1_000/*ms, timeout*/)
checkMessage()

Таким образом, нам нужно поддержать не только виртуализацию зависящих от времени методов, но и метод waitUntilThreadsAreFrozen, что сделать одновременно непросто.

Работая в Devexperts, Никита написал инструмент под названием time-test, который решает эту задачу. Давайте посмотрим, как он работает.

Time-test написан в виде Java-агента. Чтобы использовать его, нужно добавить параметр -javaagent:timetest.jar и положить его в classpath. Этот инструмент трансформирует байткод и заменяет все работающие со временем методы на вызовы своих реализаций. Написание хорошего java agent — зачастую непростая задача, поэтому Никита разработал фреймворк JAgent, который упрощает это дело.

При создании тестов нужно включить TestTimeProvider. Он реализует все необходимые методы (включая System.currentTimeMillis(), Thread.sleep(..), Object.wait(..), LockSupport.park(..) и т.п.) и перекрывает их обычную реализацию. В большинстве тестов нет никакой нужды в прямом управлении временем, используемым в нижележащей реализации. Поэтому, пока вы не подключили TestTimeProvider, инструмент продолжает использовать дефолтные релизации вышеперечисленных методов, оборачивая их своим кодом. После же подключения TestTimeProvider появляется возможность использовать методы TestTimeProvider.setTime(..), TestTimeProvider.increaseTime(..) и TestTimeProvider.waitUntilThreadsAreFrozen(..).

TimeProvider.java:

long timeMillis();
long nanoTime();
void sleep(long millis) throws InterruptedException;
void sleep(long millis, int nanos) throws InterruptedException;
void waitOn(Object monitor, long millis) throws InterruptedException;
void waitOn(Object monitor, long millis, int nanos) throws InterruptedException;
void notifyAll(Object monitor);
void notify(Object monitor);
void park(boolean isAbsolute, long time);
void unpark(Object thread);

Как было написано выше, основная проблема реализации TestTimeProvider — одновременная поддержка и методов по работе со временем, и waitUntilThreadsAreFrozen(..). Поэтому на каждое изменение времени все нужные треды вначале помечаются как работающие, и только потом будятся. Одновременно с этим waitUntilThreadsAreFrozen(..) ждёт, пока все треды не окажутся в состоянии ожидания, чтобы ни один из них не был помечен как работающий. В рамках этого подхода треды просыпаются, сбрасывают свою отметку, выполняют задачу и возвращаются в состояние ожидания — и только тогда waitUntilThreadsAreFrozen(..) поймёт, что они отработали.

Как выглядит тест с использованием TestTimeProvider:

@Before
public void setup() {
    // Use TestTimeProvider for this test
    TestTimeProvider.start(/* initial time could be passed here */);
}

@After
public void reset() {
    // Reset time provider to default after the test execution
    TestTimeProvider.reset();
}

@Test
public void test() {
    runMyConcurrentApplication();
    TestTimeProvider.increaseTime(60_000 /*ms*/);
    TestTimeProvider.waitUntilThreadsAreFrozen(1_000 /*ms*/);
    checkMyApplicationState();
}

Есть еще одна сложность с виртуализацией времени. Описанный подход хорошо работает, если нужно контролировать время во всей JVM целиком. Но ведь обычно хочется не затронуть своим вмешательством библиотеку для тестирования (типа JUnit), тред сборщика мусора и другие вещи, напрямую не относящиеся к тестируемому фрагменту кода. Поэтому обязательно нужно определять, выполняемся ли мы в тестируемом коде и стоит ли нам, исходя из этого, виртуализировать время. Для этого time-test должен знать входные точки тестируемого кода (обычно это классы тестов). Затем time-test начинает отслеживать запуски новых тредов и помечать их как «свои», что означает, что для них будет применять виртуализация времени. Однако могут возникнуть проблемы, если используется ForkJoinPool, поскольку он запускается не из тестового кода, и time-test не может понять, что необходимо виртуализировать время и там. Чтобы работать и с похожими на ForkJoinPool конструкциями, нужно расширить определение входных точек.

Думаю, теперь стало понятно, что тестирование работающей со временем функциональности может оказаться не такой уж простой задачей. Надеюсь, time-test облегчит вам жизнь, исходники можно забрать на GitHub.

Об авторе

Никита Коваль — инженер-исследователь в исследовательской группе dxLab компании Devexperts. Помимо этого, он студент кафедры Компьютерных Технологий в ИТМО, где к тому же преподает курс по многопоточному программированию. Главным образом интересуется многопоточными алгоритмами, верификацией программ и их анализом.

Минутка рекламы. Никита приедет на конференцию JBreak 2018 (которая состоится меньше чем через две недели), чтобы в докладе «На пути к быстрой многопоточной хеш-таблице» рассказать нам о практических подходах к построению высокопроизводительных алгоритмов с использованием всей мощи многоядерных архитектур. На конференции предусмотрены дискуссионные зоны, поэтому после доклада можно будет встретиться с Никитой и обсудить разные вопросы — не только многопоточные хеш-таблицы, но и описанную в статье виртуализацию времени. Билеты можно приобрести на официальном сайте.