FUTURE C# 中的单元测试调度程序答案

【问题标题】：Unit Testing Scheduler in the FUTURE C#FUTURE C# 中的单元测试调度程序
【发布时间】：2011-06-21 01:55:09
【问题描述】：

我在我的应用程序的调度程序项目（类库）中使用了quartz.NET，这是因为我希望其他项目不知道实际的实现。将来，如果我想为 Castle Scheduler 或 Windows Scheduler 或 wathever 更改石英......我将可以灵活地更改它。

我需要在我的 Quartz.NET 项目上对每周触发器进行单元测试，我开始研究并发现目前看起来很酷的解决方案 MOLES 这个扩展基本上允许我更改 DateTime.Now 并转到未来！！

在这种情况下，从现在开始一周后，当触发器被安排触发时，但在等待了一段时间后，我悲伤地发现我的触发器没有被激活，即使更改时间和 Thread.Sleeping 几分钟...

我想走向未来的原因是因为在应用程序中我为每种请求使用不同的方法/触发器。每周、每周重复、每月、每年

有其他人对这种场景进行过单元测试吗？

有什么我路过的吗？

MOLES 可以吗？

【问题讨论】：

触发器有像 GetFireTimeAfter(DateTime) 这样的方法，它会告诉你下一个预期的触发时间。测试还不够吗？
问题是我将quartz.net 包装到我自己项目的外观中，因此它对其他项目是透明的，我想从外部测试它，而不是直接在quartz.net 上触发器作为外部应用程序甚至不知道石英触发器的存在
我不敢相信没有人会遇到这种情况......

标签： c# unit-testing .net-4.0 quartz.net moles

【解决方案1】：

如何实现类似的东西

public interface IClock
{
    DateTime Now { get; }
}

public class FakeClock : IClock
{
    DateTime Now { get; set; }
}

public class SystemClock : IClock
{
    DateTime Now { get { return DateTime.Now; } }
}

当您开发外观时，您可以通过将每个对 DateTime.Now 的调用替换为 IClock.Now 来使您的代码依赖于 IClock。

IClock 依赖项可以作为构造函数参数传递，也可以直接传递给需要它的每个方法。

然后，您的生产代码将使用 SystemClock 实例，您的测试可以依赖 FakeClock 类型来操纵时间并验证某些操作确实在预期的时刻发生。

这种设计（控制反转）极大地受益于使用依赖注入容器，例如 Castle Windsor、StructureMap、AutoFac...

注意：为了进一步参考，类似的实现建议在这个post中讨论。

【讨论】：

Quartz.NET 目前的开发其实已经有了这个。只是还没有发布。
你知道什么时候发布吗？周末我想进入 QUARTZ.net 的代码并自己实现它......但我会坚持使用这个特定版本的石英，我不太喜欢......

【解决方案2】：

我还没有对此进行测试，但是当您尝试 Moles 时，您是否更改了 DateTimeOffset 或 DateTime？ Quartz.Net 使用 DateTimeOffset.UtcNow：

https://fisheye3.atlassian.com/browse/quartznet/src/Quartz/SystemTime.cs?hb=true

我认为你应该能够在不使用痣的情况下做到这一点，虽然我也没有测试过，只是写

SystemTime.UtcNow = () => new DateTimeOffset(DateTime.Now.AddDays(5)).UtcNow

当你想成为未来五天的时候:)

请注意，SystemTime 功能要求您从源代码构建 Quartz，您可以在 github 上获取源代码：

https://github.com/lahma/quartznet

【讨论】：