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