C# 单元测试基于计时器的应用程序？

Unit testing a timer based application?

提问by Erik ?jebo

I am currently writing a simple, timer based mini app in C# that performs an action n times every k seconds.
I am trying to adopt a test driven development style, so my goal is to unit test all parts of the app.

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

So, my question is: Is there a good way to unit test a timer based class?

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

The problem, as I see it, is that there is a big risk that the tests will take uncomfortably long to execute, since they must wait so and so long for the desired actions to happen.
Especially if one wants realistic data (seconds), instead of using the minimal time resolution allowed by the framework (1 ms?).
I am using a mock object for the action, to register the number of times the action was called, and so that the action takes practically no time.

正如我所看到的，问题在于测试执行的时间会很长，这会带来很大的风险，因为它们必须等待很长时间才能发生所需的操作。
特别是如果你想要真实的数据（秒），而不是使用框架允许的最小时间分辨率（1 毫秒？）。
我正在为该操作使用模拟对象，以注册该操作被调用的次数，因此该操作几乎不需要时间。

采纳答案by David Sykes

What I have done is to mock the timer, and also the current system time, that my events could be triggered immediately, but as far as the code under test was concerned time elapsed was seconds.

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

回答by TheSmurf

I think what I would do in this case is test the code that actually executes when the timer ticks, rather than the entire sequence. What you really need to decide is whether it is worthwhile for you to test the actual behaviour of the application (for example, if what happens after every tick changes drastically from one tick to another), or whether it is sufficient (that is to say, the action is the same every time) to just test your logic.

我想在这种情况下我会做的是测试计时器滴答时实际执行的代码，而不是整个序列。您真正需要决定的是，测试应用程序的实际行为是否值得（例如，如果每次滴答后发生的情况从一个滴答到另一个滴答发生剧烈变化），或者是否足够（也就是说，每次的动作都是一样的）来测试你的逻辑。

Since the timer's behaviour is guaranteed never to change, it's either going to work properly (ie, you've configured it right) or not; it seems to be to be wasted effort to include that in your test if you don't actually need to.

由于定时器的行为保证永远不会改变，它要么会正常工作（即，您已正确配置它）要么不会；如果您实际上不需要，将其包含在您的测试中似乎是浪费精力。

回答by graham.reeds

Len Holgatehas a series of 20 articles on testing timer based code.

Len Holgate有20 篇关于测试基于计时器的代码的系列文章。

回答by Mike Deck

I agree with Danny insofar as it probably makes sense from a unit-testing perspective to simply forget about the timer mechanism and just verify that the action itself works as expected. I would also say that I disagree in that it's wasted effort to include the configuration of the timer in an automated test suite of some kind. There are a lot of edge cases when it comes to working with timing applications and it's very easy to create a false sense of security by only testing the things that are easy to test.

我同意 Danny 的观点，因为从单元测试的角度来看，简单地忘记计时器机制并验证操作本身是否按预期工作可能是有意义的。我还要说我不同意，因为将计时器的配置包含在某种自动化测试套件中是浪费精力。在使用计时应用程序时有很多边缘情况，并且很容易通过仅测试易于测试的事物来创建虚假的安全感。

I would recommend having a suite of tests that runs the timer as well as the real action. This suite will probably take a while to run and would likely not be something you would run all the time on your local machine. But setting these types of things up on a nightly automated build can really help root out bugs before they become too hard to find and fix.

我建议有一套测试来运行计时器以及实际操作。该套件可能需要一段时间才能运行，并且可能不会一直在本地计算机上运行。但是在夜间自动构建中设置这些类型的东西确实可以帮助在错误变得难以找到和修复之前将其根除。

So in short my answer to your question is don't worry about writing a few tests that do take a long time to run. Unit test what you can and make that test suite run fast and often but make sure to supplement that with integration tests that run less frequently but cover more of the application and its configuration.

所以简而言之，我对您的问题的回答是不要担心编写一些需要很长时间才能运行的测试。单元测试你能做的，让测试套件快速和频繁地运行，但确保用运行频率较低但覆盖更多应用程序及其配置的集成测试来补充它。