我目前正在用 C# 编写一个简单的、基于计时器的迷你应用程序，该应用程序每
nk所以，我的问题是：有没有一个好的方法来对基于计时器的类进行单元测试？
在我看来，问题在于存在很大的风险，即测试将花费令人不舒服的长时间来执行，因为它们必须等待很长时间才能发生所需的操作。
特别是如果想要真实的数据 (
seconds1 ms我所做的是模拟计时器，以及当前的系统时间，以便我的事件可以立即触发，但就被测试的代码而言，流逝的时间是秒。
我认为在这种情况下我要做的是测试计时器滴答时实际执行的代码，而不是整个序列。您真正需要决定的是是否值得您测试应用程序的实际行为（例如，如果每个刻度之后发生的情况从一个刻度到另一个刻度发生巨大变化），或者是否足够（也就是说，每次的动作都是一样的）只是为了测试你的逻辑。
由于计时器的行为保证永远不会改变，所以它要么正常工作（即，您已经正确配置了它），要么不正常工作；如果您实际上不需要的话，将其包含在您的测试中似乎是浪费精力。
我同意丹尼的观点，因为从单元测试的角度来看，简单地忘记计时器机制并验证操作本身是否按预期工作可能是有意义的。我还想说，我不同意将计时器的配置包含在某种自动化测试套件中是浪费精力。在使用计时应用程序时，存在很多边缘情况，并且仅测试易于测试的内容很容易造成错误的安全感。
我建议进行一套运行计时器和实际操作的测试。该套件可能需要一段时间才能运行，并且您可能不会一直在本地计算机上运行。但是，在夜间自动构建中设置这些类型的东西确实可以帮助在错误变得难以查找和修复之前根除它们。
简而言之，我对你问题的回答是，不要担心编写一些需要很长时间才能运行的测试。对你能做的进行单元测试，使测试套件快速且频繁地运行，但确保用运行频率较低但涵盖更多应用程序及其配置的集成测试来补充。