单元测试中处理DateTime.Now的策略我的业务逻辑在周六或周日不执行某些功能。我希望我的单元测试能够验证功能是否已执行，但测试将在周六/周日失败。我认为最简单的方法是让单元测试传达一个友好的信息，如果在周六/周日运行测试结果是无效的。在C#/NUnit中...Assert.That(DateTime.Now.DayOfWeek!=DayOfWeek.Sunday&&DateTime.Now.DayOfWeek!=DayOfWeek.Saturday,"此测试不能在周六或周日运行");试图嘲笑日期是否可行/可取？是否有其他策略来处理这种情况？尝试嘲笑约会是否可能/可取？是的，这不仅是可能的，而且是可靠地隔离测试代码的唯一方法。假设您想测试以下（无意义的）方法：publicboolFoo(){return(DateTime.Now.DayOfWeek==DayOfWeek.Sunday);显然，您无法测试它，因为它依赖于静态方法（staticNow属性更准确）。很明显，像这样紧密耦合的组件不能单独进行单元测试。现在考虑这种改进（将关注点与构造函数DI分离）：privatereadonlyFunc_nowProvider；publicSomeClass(FuncnowProvider){_nowProvider=nowProvider;}publicboolFoo(){return(_nowProvider().DayOfWeek==DayOfWeek.Sunday);现在，单元测试更好更容易了。SomeClass不再依赖于不确定的日期。在实际应用程序中，您显然会像这样实例化SomeClass：vars=newSomeClass(()=>DateTime.Now);s.Foo();在你的单元测试中，你会模拟它以便你可以验证这两种情况：varsubjectUnderTest=newSomeClass(()=>newDateTime(2011,1,3));varactual=subjectUnderTest.Foo();//assertions,...你应该在系统时钟上创建一个抽象，因为你应该创建其他系统资源和外部资源的抽象，以便能够编写RTMunit测试。系统时钟的抽象非常简单，看起来像这样：publicinterfaceISystemClock{DateTimeNow{get;应用程序中依赖于系统时钟的类通常应将ISystemClock作为构造函数参数。对于单元测试场景，您可以像这样使用ISystemClock实现：publicclassFakeSystemClock:ISystemClock{//注意setter。公共日期时间现在{得到;放;现在你可以在你的单元测试中使用这个假时钟，如下所示：安排varsaturday=newDateTime(2011,1,);Assert.AreEqual(saturday.DayOfWeek,DayOfWeek.Saturday,"测试设置失败");varclock=newFakeSystemClock(){现在=星期六};var服务=新服务（时钟）；//行动service.DoSomething();在您的应用程序项目中，您可以定义实际使用系统时钟的ISystemClock实现。使用给定的ISystemClock定义，它看起来像这样：publicclassRealSystemClock:ISystemClock{publicDateTimeNow=>DateTime.Now;当使用DI容器时，可以配置为连接类型，当构造函数指定ISystemClock参数时自动注入RealSystemClock实例。顺便一提。虽然您可以使用Func委托来执行此操作，但为此定义一个接口对于其他开发人员来说更加明确和可读。除此之外，将所有内容都连接到DI容器中会容易得多，因为它很容易以多个Func依赖项结束，所有这些依赖项都不同于“给我当前本地时间”。我希望这有帮助。以上就是《C#学习教程：单元测试中处理DateTime.Now的策略》的全部内容。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场，如涉及侵权，请点击右边联系管理员删除。如需转载请注明出处：
