2008-08-15 22 views
18

我目前正在C#中编写一个简单的基于计时器的迷你应用程序,每k秒执行一次动作n次。
我试图采用测试驱动的开发风格,所以我的目标是单元测试应用程序的所有部分。单元测试基于计时器的应用程序?

所以,我的问题是:有单位测试基于计时器的类的好方法吗?

正如我所看到的那样,问题在于测试将花费很长的时间执行很大的风险,因为他们必须等待期望的动作发生。
特别是如果你想要现实的数据(秒),而不是使用框架允许的最小时间分辨率(1毫秒?)。
我正在使用模拟对象执行操作,注册操作次数被调用的次数,以便该操作几乎不需要任何时间。

回答

9

我所做的就是模拟计时器和当前系统时间,我的事件可以立即触发,但是就测试中的代码而言,时间流逝是秒。

3

我想在这种情况下我会做的是测试当计时器滴答时实际执行的代码,而不是整个序列。你真正需要决定的是,测试应用程序的实际行为是否值得(例如,如果在每个时间点之间发生的变化从一个时间点到另一个时间点发生剧烈变化),还是足够了(也就是说,每次操作都是一样的)来测试你的逻辑。由于定时器的行为保证永不改变,它可以正常工作(也就是说,你已经正确配置了它);或者不是,如果你实际上不需要,似乎是浪费精力将它包含在你的测试中。

+1

我看到你的方法唯一的问题是,你可能不得不暴露每次民意调查发生的事情,这是一个好主意吗?即暴露你不需要进行测试的东西。另一种选择可能是内部的(和InternalsVisibleTo),但很多人也不喜欢这样做 – roundcrisis 2012-09-13 11:22:37

1

我同意丹尼的观点,因为从单元测试的角度来看,它可能有意义,只是忘记了计时器机制,只验证动作本身如预期那样工作。我也会说我不同意,因为把定时器的配置包含在某种自动化测试套件中是浪费时间的。在处理定时应用程序时有很多边缘情况,只通过测试容易测试的东西来创建错误的安全感很容易。

我会建议有一套测试运行计时器以及实际行动。该套件可能需要一段时间才能运行,并且可能不会在本地计算机上始终运行。但是,在夜间自动构建这些类型的东西时,确实有助于在错误难以发现和修复之前消除错误。

所以总之,我对你的问题的回答是不用担心编写几个需要很长时间才能运行的测试。单元测试你可以做什么,并使这个测试套件能够快速而经常地运行,但是确保使用运行频率较低但涵盖更多应用程序及其配置的集成测试进行补充。

相关问题