关于c＃：对基于计时器的应用程序进行单元测试？

Unit testing a timer based application?

我目前正在用C＃编写一个简单的基于计时器的微型应用程序，该应用程序每k秒执行n次操作。
我正在尝试采用测试驱动的开发风格，因此我的目标是对应用程序的所有部分进行单元测试。

所以，我的问题是：有没有一种好的方法可以对基于计时器的类进行单元测试？

正如我所看到的那样，问题在于，存在很大的风险，即执行这些测试会花费很长时间，因为它们必须等待这么长时间才能执行所需的操作。
尤其是如果想要真实的数据(秒)，而不是使用框架允许的最小时间分辨率(1毫秒？)。
我正在为动作使用模拟对象，以注册该动作被调用的次数，因此该动作几乎不需要时间。

Len Holgate撰写了20篇有关测试基于计时器的代码的文章。

我要做的是模拟计时器以及当前的系统时间，以便可以立即触发我的事件，但是就所测试的代码而言，经过的时间仅为几秒钟。

我认为在这种情况下，我要做的是测试计时器滴答时实际执行的代码，而不是整个序列。您真正需要决定的是，是否值得测试应用程序的实际行为(例如，是否在每个滴答声从一个滴答声急剧变化到另一个滴答声之后发生了什么)，或者是否足够(也就是说，每次操作都相同)，只是测试您的逻辑。

由于保证了计时器的行为永不改变，因此它要么正常工作(即，您已正确配置)，要么不正确。如果您实际上不需要的话，将其包含在测试中似乎是浪费了。

我同意Danny的观点，因为从单元测试的角度来看，简单地忘记计时器机制并验证动作本身是否按预期工作可能是有意义的。我还要说我不同意，因为浪费了将计时器的配置包含在某种自动化测试套件中的努力。与计时应用程序一起使用时，存在很多极端情况，仅通过测试易于测试的事物就很容易产生错误的安全感。

我建议您进行一整套测试，以运行计时器以及实际操作。该套件可能需要一段时间才能运行，并且可能不会一直在本地计算机上运行。但是在夜间自动构建中设置这些类型的内容确实可以帮助在错误变得难以发现和修复之前消除错误。

简而言之，我对您问题的回答是，不必担心编写一些需要很长时间才能运行的测试。进行单元测试可以使测试套件快速且经常地运行，但是请确保使用集成测试来补充它，该测试运行频率较低，但涵盖了更多的应用程序及其配置。