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

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

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

解决方案

回答

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

由于保证了计时器的行为永远不会改变，所以它或者正常工作(即，我们已经正确配置了它)，或者不正确。如果我们实际上不需要的话，将其包含在测试中似乎是浪费了。

回答

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

回答

Len Holgate在测试基于计时器的代码方面有20篇文章。

回答

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

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

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