Залежні від часу одиничні тести

Мені потрібно протестувати функцію, результат якої буде залежати від поточного часу (з використанням часу Joda isBeforeNow()це трапляється).

public boolean isAvailable() {
    return (this.someDate.isBeforeNow());
}

Чи можна заглушити / висміяти системний час за допомогою (наприклад, використовуючи Mockito), щоб я міг надійно перевірити функцію?

Joda time підтримує встановлення "фальшивого" поточного часу за допомогою setCurrentMillisFixedі setCurrentMillisOffsetметодів DateTimeUtilsкласу.

Див. Https://www.joda.org/joda-time/apidocs/org/joda/time/DateTimeUtils.html

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

Я використовував цей підхід у різних ситуаціях, і він працював добре. Це легко налаштувати - просто створіть інтерфейс (наприклад Clock), який має єдиний метод, щоб надати вам поточний момент у будь-якому форматі, який ви хочете (наприклад, використовуючи Joda Time, або, можливо, a Date).

Java 8 представила абстрактний клас, java.time.Clockякий дозволяє використовувати альтернативну реалізацію для тестування. Це саме те, що Джон запропонував у своїй відповіді тоді.

Щоб додати до відповіді Джона Скіта , Joda Time вже містить поточний інтерфейс часу: DateTimeUtils.MillisProvider

Наприклад:

import org.joda.time.DateTime;
import org.joda.time.DateTimeUtils.MillisProvider;

public class Check {
    private final MillisProvider millisProvider;
    private final DateTime someDate;

    public Check(MillisProvider millisProvider, DateTime someDate) {
        this.millisProvider = millisProvider;
        this.someDate = someDate;
    }

    public boolean isAvailable() {
        long now = millisProvider.getMillis();
        return (someDate.isBefore(now));
    }
}

Здійснюйте час в юніт-тесті (використовуючи Mockito, але ви можете реалізувати свій власний клас MillisProviderMock):

DateTime fakeNow = new DateTime(2016, DateTimeConstants.MARCH, 28, 9, 10);
MillisProvider mockMillisProvider = mock(MillisProvider.class);
when(mockMillisProvider.getMillis()).thenReturn(fakeNow.getMillis());

Check check = new Check(mockMillisProvider, someDate);

Використовуйте поточний час у виробництві ( DateTimeUtils.SYSTEM_MILLIS_PROVIDER додано до Joda Time у 2.9.3):

Check check = new Check(DateTimeUtils.SYSTEM_MILLIS_PROVIDER, someDate);

Я використовую підхід, схожий на підхід Джона, але замість того, щоб створювати спеціалізований інтерфейс лише на поточний час (скажімо, Clock), я зазвичай створюю спеціальний інтерфейс тестування (скажімо, MockupFactory). Я помістив туди всі методи, які мені потрібні для тестування коду. Наприклад, в одному зі своїх проектів у мене є чотири методи:

• той, який повертає макет клієнта бази даних;
• той, який створює макет об’єкта-сповіщувача, який повідомляє код про зміни в базі даних;
• той, який створює макет java.util.Timer, який запускає завдання, коли я цього хочу;
• той, що повертає поточний час.

Тестований клас має конструктор, який приймає цей інтерфейс серед інших аргументів. Той без цього аргументу просто створює екземпляр цього інтерфейсу за замовчуванням, який працює "в реальному житті". І інтерфейс, і конструктор є приватними для пакету, тому API тестування не витікає за межі пакету.

Якщо мені потрібні більш імітовані об'єкти, я просто додаю метод до цього інтерфейсу та впроваджую його як у тестуванні, так і в реальних реалізаціях.

Таким чином я розробляю код, придатний для тестування, в першу чергу, не накладаючи занадто багато на сам код. Насправді, таким чином код стає ще чистішим, оскільки багато заводських кодів зібрано в одному місці. Наприклад, якщо мені потрібно перейти до іншої реалізації клієнта бази даних у реальному коді, мені потрібно лише змінити лише один рядок, замість того, щоб шукати посилання на конструктор.

Звичайно, як і у випадку з підходом Джона, він не буде працювати зі стороннім кодом, який ви не можете або не можете змінити.