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

Question

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

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

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

Answer 1

Лен Холгейт опубликовал серию статей 20 по тестированию кода на основе таймера .

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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