Хотя простое тестирование задания (не дожидаясь, пока планировщик запустит его для вас) поможет в большинстве (читайте это как: вероятно, все) ситуациях, есть некоторые, в которых может быть интересно не запускатьэто вручную.
Например, у вас есть кластер приложений воспроизведения, которые используют общий набор конфигурации.Измените один конфиг в одном подчиненном устройстве, все остальные примут к сведению и сделают то же самое.Допустим, конфигурация хранится в memcached.Один полезный модульный тест состоит в том, чтобы вручную изменить некоторые настройки с помощью Cache.set, подождать, сколько времени потребуется для выполнения задания configurationObserver, а затем проверить, что внутренняя конфигурация обновлена.Это было бы еще более полезно, если бы была серия заданий по обновлению конфигурации и т. Д.
Чтобы сделать это, вы должны помнить, что игра в режиме DEV использует один поток (кстати, это помогает отладку, кстати),Вы можете просто добавить эту строку в ваш application.conf:% test.application.mode = prod, и у вас будет несколько потоков.
Позднее редактирование: кажется, что установка режима на prod на самом деле не помогаетв этом случае.Что помогает, так это: используйте магию «жду».
@Test
public void myTest() {
final Lock lock = new ReentrantLock();
final Condition goAhead = lock.newCondition();
/* Here goes everything you need to do before "pausing" */
lock.lock();
try {
/**
* Set whatever time limit you want/need
* You can also use notifiers like goAhead.signal(), from within another thread
*/
goAhead.await(5, TimeUnit.SECONDS);
} catch (InterruptedException e) {
assertTrue(whateverINeedToTest);
} finally {
lock.unlock();
}
}