单元测试基于计时器的应用？

Question

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

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

正如我所看到的那样，问题在于，测试执行时会有很长的风险，因为他们必须等待很长时间才能完成所需的操作。 特别是如果想要实际数据（秒），而不是使用框架允许的最小时间分辨率（1毫秒？） 我正在使用模拟对象来执行操作，以记录操作被调用的次数，以便操作几乎没有时间。

Answer 1

Len Holgate有一系列20 articles on testing timer based code。

Answer 2

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

Answer 3

我认为在这种情况下我要做的是测试在计时器滴答时实际执行的代码，而不是整个序列。你真正需要决定的是，你是否值得测试应用程序的实际行为（例如，如果每个滴答在一个滴答之间发生了什么变化，或者它是否足够）（也就是说它是否足够） ，每次动作都是一样的，只是测试你的逻辑。

由于保证定时器的行为永远不会改变，因此它可以正常工作（即，你已经正确配置）或不行;如果你实际上不需要，那么在你的测试中包含它似乎是浪费的努力。

Answer 4

我同意Danny的意见，因为从单元测试的角度来看，简单地忘记计时器机制并且只是验证操作本身是否按预期工作可能是有意义的。我还要说，我不同意的是，将计时器的配置包含在某种自动测试套件中是浪费精力。在处理计时应用程序时有很多边缘情况，只通过测试易于测试的东西就很容易造成错误的安全感。

我建议使用一套运行计时器和实际操作的测试。这个套件可能需要一段时间才能运行，可能不会是你在本地机器上一直运行的东西。但是，在夜间自动构建中设置这些类型的东西可以真正帮助根除错误，直到它们变得难以找到和修复。

所以简而言之，我对你的问题的回答是不要担心编写一些需要很长时间才能运行的测试。单元测试你可以做什么，并使测试套件快速且经常运行，但确保通过不那么频繁运行的集成测试来补充，但覆盖了更多的应用程序及其配置。