Comments 9
(doomTime — System.currentTimeMillis()) / millisInDay
Вообще говоря количество миллисекунд в одном дне разное, так что здесь баг. Можете проверить на достаточно большом интервале.
Используя простейший подход из примера выше и подменив System.currentTimeMillis(), можно проверить корректность сообщения и только. Но чтобы протестировать корректность расписания, придётся ждать целый день.
Посыл правильный, реализация куда-то в сторону уехала.
Верно отмечено, тестировать нужно корректность расписания. Оборачиваем System.currentTimeMillis() в отдельный метод в нашем классе, и мокаем его (наш метод) в тестах с любой логикой, которой нужно для тестов.
Что не умоляет (наверно) возможностей time-test, в тех случаях, когда System.currentTimeMillis() зовется где-то в недрах внешней библиотеки, которую сложно отмокать.
Thread.sleep(ONE_DAY) что делать будете?Опять же, вопрос: когда я cмогу быть уверен, что сообщение уже напечаталось или не печатолось вовсе? У time-test для этого есть метод
waitUntilThreadsAreFrozen(..).Если вам нужно протестировать поведение Thread.sleep, вопросов нет. Так и надо делать.
Если вы доверяете Thread.sleep, и вам нужно проверить реализацию вашего класса, в котором каким-то образом обыграны настройки расписания, то вам нужно тестировать параметры, передаваемые в Thread.sleep, и которые генерируются из настроек расписания (т.е. протестировать тот код, который написали лично вы). В этом случае, опять же оборачиваете Thread.sleep в отдельный метод, и мокаете его в тестах. Если не убедил, представьте что вместо Thread.sleep, у вас Files.readAllBytes, или new Random().nextInt.
Вы определитесь с тем, что тестировать собираетесь. Если вы хотите протестировать корректность сообщения, то вопросов нет, нужно всего-лишь заменить вызов System.currentTimeMillis() на вызов своей реализации (как — вопрос десятый) и тестировать только метод вывода сообщения, без засыпания на сутки. Однако, если вы хотите протестировать, что сообщение выводится действительно каждый день, то вам придется подождать целый день для проведения теста. При этом ни на какую корректность Thread.sleep() вы полагаться в реальном коде не можете, т.к. в таком случае закладываетесь на реализацию через этот Thread.sleep(), который в любой момент будет заменён Timer-ом или каким-нибудь wait-ом (тут вы вообще ничего не сделаете со своим подходом). Не пытайтесь решать игрушечную проблему, подумайте о реальном коде.
Вот ещё пример для размышления. У вас есть файл, в который пишутся приходящие события, и который должен быть закрыт, если в течение минуты ничего не приходит. Логично для передачи событий использовать BlockingQueue и делать poll() с таймаутом. И с такой реализацией я не представляю как вы будете тестировать тот факт, что файл через минуту действительно закрывается.
Машина времени на Java