我目前正在用 C# 编写一个简单的、基于计时器的迷你应用程序，它每 k 秒执行一次操作 n 次。
我正在尝试采用测试驱动的开发风格，所以我的目标是对应用程序的所有部分进行单元测试。
所以，我的问题是：有没有一种对基于计时器的类进行单元测试的好方法？
正如我所看到的，问题在于测试执行的时间会非常长，这是一个很大的风险，因为它们必须等待很长时间才能发生所需的操作。
特别是如果想要真实的数据（秒），而不是使用框架允许的最小时间分辨率（1 毫秒？）。
我正在为动作使用模拟对象，以记录动作被调用的次数，这样动作几乎不需要时间。
我所做的是模拟计时器以及当前系统时间，以便我的事件可以立即触发，但就被测代码而言，经过的时间是几秒钟。
Len Holgate有20 篇关于测试基于计时器的代码的系列文章。
我认为在这种情况下我要做的是测试计时器滴答时实际执行的代码，而不是整个序列。您真正需要决定的是是否值得您测试应用程序的实际行为（例如，如果每个滴答从一个滴答到另一个滴答发生剧烈变化之后发生的情况），或者是否足够（也就是说，每次的动作都是一样的）来测试你的逻辑。
由于定时器的行为保证永远不会改变，它要么正常工作（即，你配置正确）要么不正常；如果您实际上不需要，将其包含在您的测试中似乎是浪费精力。
我同意 Danny 的观点，因为从单元测试的角度来看，简单地忘记计时器机制并验证操作本身是否按预期工作可能是有意义的。我还要说我不同意，将计时器的配置包含在某种自动化测试套件中是浪费精力。在使用计时应用程序时有很多边缘情况，并且很容易通过只测试易于测试的东西来产生错误的安全感。
我建议有一套运行计时器以及实际操作的测试。该套件可能需要一段时间才能运行，而且您可能不会一直在本地计算机上运行。但是在夜间自动构建中设置这些类型的东西可以真正帮助在错误变得难以找到和修复之前根除错误。
所以简而言之，我对你的问题的回答是不要担心编写一些需要很长时间才能运行的测试。尽可能进行单元测试，使测试套件快速且频繁地运行，但请确保使用运行频率较低但涵盖更多应用程序及其配置的集成测试来补充这一点。