Модульное тестирование приложения на основе таймера?

В настоящее время я пишу простое мини-приложение, основанное на таймере, на C #, которое выполняет действие n раз каждые k секунд.
Я пытаюсь принять тестовый стиль разработки, поэтому моя цель - провести модульное тестирование всех частей приложения.

Итак, мой вопрос: есть ли хороший способ для модульного тестирования класса на основе таймера?

Проблема, на мой взгляд, заключается в том, что существует большой риск того, что выполнение тестов займет слишком много времени, так как они должны ждать так долго, пока не произойдут желаемые действия.
Особенно, если вам нужны реалистичные данные (секунды) вместо использования минимального временного разрешения, разрешенного платформой (1 мс?).
Я использую фиктивный объект для действия, чтобы зарегистрировать, сколько раз было вызвано действие, и чтобы действие практически не занимало время.

15.08.2008 07:02:45
4 ОТВЕТА
РЕШЕНИЕ

Что я сделал, так это издевался над таймером, а также над текущим системным временем, чтобы мои события могли запускаться немедленно, но что касается тестируемого кода, то время, прошедшее, составляло секунды.

9
15.08.2008 07:43:18

Я думаю, что в этом случае я бы протестировал код, который фактически выполняется при срабатывании таймера, а не всю последовательность. Что вам действительно нужно решить, так это то, стоит ли вам тестировать реальное поведение приложения (например, если то, что происходит после каждого тика, резко меняется с одного тика на другое), или достаточно ли этого (то есть действие всегда одно и то же), чтобы просто проверить свою логику.

Поскольку поведение таймера гарантированно никогда не изменится, он либо будет работать должным образом (т. Е. Вы настроили его правильно), либо нет; кажется, что это будет напрасной тратой усилий, чтобы включить это в ваш тест, если вам это не нужно.

3
15.08.2008 07:09:04
Единственная проблема, которую я вижу в вашем подходе, заключается в том, что вам, вероятно, придется раскрывать то, что происходит каждый раз, когда происходят опросы. Это хорошая идея? то есть разоблачение чего-то, что вам не нужно просто для испытаний. Альтернативой может быть внутренняя (и InternalsVisibleTo), но многим это тоже не нравится
roundcrisis 13.09.2012 11:22:37

Я согласен с Дэнни, поскольку с точки зрения модульного тестирования, вероятно, имеет смысл просто забыть о механизме таймера и просто убедиться, что само действие работает так, как ожидалось. Я также хотел бы сказать, что я не согласен с тем, что было потрачено впустую усилие по включению конфигурации таймера в некоторый набор автоматизированных тестов. Есть много крайних случаев, когда речь идет о работе с приложениями синхронизации, и очень легко создать ложное чувство безопасности, проверяя только те вещи, которые легко проверить.

Я бы порекомендовал иметь набор тестов, который запускает таймер, а также реальные действия. Этот пакет, вероятно, займет некоторое время для запуска и, вероятно, не будет тем, что вы будете запускать все время на своей локальной машине. Но настройка этих типов вещей на ночные автоматизированные сборки может действительно помочь устранить ошибки, прежде чем их станет слишком трудно найти и исправить.

Короче говоря, я отвечаю на ваш вопрос: не беспокойтесь о написании нескольких тестов, выполнение которых занимает много времени. Проведите модульное тестирование того, что вы можете, и сделайте этот набор тестов быстрым и частым, но обязательно дополните его интеграционными тестами, которые запускаются реже, но охватывают большую часть приложения и его конфигурации.

1
15.08.2008 21:28:51