Поблочное тестирование с тайм-аутами
Я - поблочное тестирование класс со свойством, значение которого часто изменяется, в зависимости от коммуникации, которую это получает от другого компонента. Если класс не получает коммуникации в течение 5 секунд, свойство возвращается к значению по умолчанию.
Это легко для меня к тупику и насмешке связывающийся компонент для инициирования значений, на которые я хочу протестировать. Проблема состоит в том, что, если я выполняю свои модульные тесты на машине, которая занята (как машина сборки), и существует достаточно значительная задержка, чтобы заставить свойство принимать значение по умолчанию, затем мой модульный тест перестанет работать.
Как Вы протестировали бы, чтобы быть уверенными, что это свойство имеет собственное значение при моделировании различных коммуникационных условий?
Одна идея состоит в том, чтобы реструктурировать мой код так, чтобы я мог заблокировать часть класса, который управляет тайм-аутом. Другой должен записать мой модульный тест, таким образом, что он может обнаружить, если он перестал работать из-за тайм-аута и указывает на это в результатах испытаний.
3 ответа
Вы можете сделать свойство тайм-аута настраиваемым, а затем установить для него достаточно высокое значение в ваших модульных тестах (или достаточно низкое, если вы хотите провести модульное тестирование поведения сброса).
Я бы попробовал другой подход. Разработчикам игр часто нужен способ управления игровым временем, например, для перемотки вперед или для синхронизации частоты кадров. Они вводят объект Timer, который считывает тики либо с аппаратных часов, либо с симулированных часов.
В вашем случае вы могли бы предоставить управляемый таймер для ваших модульных тестов и таймер, который делегирует системное время в производственном режиме. Таким образом, вы можете контролировать время, которое проходит для вашего тестового случая, и, следовательно, как класс под тестом должен реагировать при определенных условиях таймаута.
Pseudo-code:
public void testTimeout() throws Exception {
MockTimerClock clock = new MockTimerClock();
ClassUnderTest cut = new ClassUnderTest();
cut.setTimerClock(clock);
cut.beginWaitingForCommunication();
assertTrue(cut.hasDefaultValues());
cut.receiveOtherValues();
assertFalse(cut.hasDefaultValues());
clock.tick(5,TimeUnit.SECONDS);
assertTrue(cut.hasDefaultValues());
cut.shutdown();
}
Существует аналогичная проблема при использовании DateTime.Now.
Ayende описал трюк для решения этой проблемы, который мне понравился:
public static class SystemTime
{
public static Func<DateTime> Now = () => DateTime.Now;
}
и затем в вашем тесте:
[Test]
public void Should_calculate_length_of_stay_from_today_when_still_occupied()
{
var startDate = new DateTime(2008, 10, 1);
SystemTime.Now = () => new DateTime(2008, 10, 5);
var occupation = new Occupation { StartDate = startDate };
occupation.LengthOfStay().ShouldEqual(4);
}
Может быть, вы можете использовать такой же трюк для вашего таймаута?