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

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

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

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

4 ответа

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

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

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

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

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

    Короче говоря, мой ответ на ваш вопрос: не беспокойтесь о написании нескольких тестов, которые занимают много времени. Unit test what you can and make that test suite run fast and frequently but make sure to supplement that with integration tests that run less frequently but cover more of the application and its configuration.