Единичное тестирование приложения на основе таймера?

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

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

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

Ответ 1

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

Ответ 2

Len Holgate имеет серию 20 статей по тестированию кода на основе таймера.

Ответ 3

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

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

Ответ 4

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

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

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