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