У меня есть класс удобных методов, относящихся к DateTime, который получает такие вещи, как текущий год или текущий час. Я только что обновил все это, чтобы использовать классы java.time. *, И пытаюсь написать хорошие тесты JUnit 5, чтобы убедиться, что они работают правильно.
Очевидно, мне нужно определить ожидаемый результат для сравнения с каждым фактическим результатом, но мне сложно придумать хороший способ вычислить ожидаемого результата. (Жесткое кодирование ожидаемого значения не очень удовлетворительно для таких значений, как текущий час, минута или секунда, и даже большие единицы, такие как день, проблематичны, если я не провожу тестирование в день, указанный в ожидаемых результатах.)
Мои методы основаны на методе LocalDate.now (), поэтому вычислять ожидаемые результаты с использованием того же метода кажется бессмысленным; это может только доказать, что ожидаемые и фактические результаты совпадают, но ОБА НЕПРАВИЛЬНО. Это разумное возражение?
Если да, то как мне рассчитать ожидаемые результаты? Многие из старых классов даты и времени в значительной степени устарели, и все знают об их недостатках. Должен ли я использовать их в любом случае и надеяться, что ни один из этих недостатков не даст мне ложных срабатываний или отрицательных результатов?
Или есть лучший способ продолжить?
@Tomaz Fernandes - так вы хотите, чтобы я протестировал LocalDate.now () на нем самом? Как это могло когда-либо дать те же самые ответы, которые мог бы были неправильными ответами?
@ Оле В.В. - Вы предлагаете мне проверить часы, используемые LocaleDate.now (), на других часах? Для меня это имеет гораздо больший смысл :-) Спасибо!
Я говорю, что вам не нужно тестировать классы java ... Если ваш метод возвращает текущий год, ваш тест должен проверить его на LocalDate.now (). GetYear (), а затем продолжить свою жизнь ... В противном случае у вас гораздо больше шансов создать ошибку в вашем наборе тестирования, чем в вашем служебном классе, что нарушает цель тестирования. В общем, это всего лишь мои два цента :)
Но, глядя на ответ Генри, похоже, что есть вариант, в котором вы можете принудительно установить часы LocalDate на определенное значение, так что это, безусловно, лучше ... Собираюсь исследовать это.




Мне кажется, вы пытаетесь написать тест для класса LocalDate ... Если ваш метод возвращает LocalDate.now (), это именно то, с чем вы должны его протестировать.