我在应用程序的调度器项目(类库)中使用quartz.NET,这是因为我希望其他项目与实际实现无关。将来,如果我想将quartz更改为Castle Scheduler或Windows Scheduler或wathever...我将拥有更改它的灵活性。
我需要对我的Quartz.NET项目每周一次的触发器进行单元测试,我开始研究并发现了一个目前看起来很酷的解决方案MOLES这个扩展基本上允许我更改DateTime.Now并进入未来!!
在这种情况下,一周后,当触发器被计划触发,但等待了一小段时间后,我遗憾地发现我的触发器没有被激活,即使改变时间和Thread.Sleeping几分钟也是如此……
我想转到未来的原因是因为在应用程序中,我对每种类型的请求使用不同的方法/触发器,例如,每周、每周和重复、每月、每年
有没有人测试过这种情况?
我是不是错过了什么?
有没有可能使用MOLES?
发布于 2011-02-05 12:11:26
实现像这样的东西怎么样
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中讨论。
发布于 2011-04-01 04:43:07
我还没有测试过这个,但是当你尝试Moles的时候,你改变了DateTimeOffset或者DateTime吗?Quartz.Net使用DateTimeOffset.UtcNow:
https://fisheye3.atlassian.com/browse/quartznet/src/Quartz/SystemTime.cs?hb=true
虽然我也没有测试过,但我认为你不需要使用moles也可以做到这一点,只需写下
SystemTime.UtcNow = () => new DateTimeOffset(DateTime.Now.AddDays(5)).UtcNow
当你想进入未来的五天时:)
请注意,SystemTime-functionality要求您从源代码构建Quartz,您可以从github获得源代码:
https://stackoverflow.com/questions/4893510
复制