使用DateTimeOffset对象的单元测试类的正确方法？(Correct way of unit

使用DateTimeOffset对象的单元测试类的正确方法？(Correct way of unit-testing classes that use DateTimeOffset objects?)

我将非常感谢有关如何正确测试使用DateTimeOffset实例的代码的信息或示例。 我知道测试必须是确定性的。

那么，如何将应用程序与DateTimeOffset类隔离开来呢？ 当然，我希望能够使用假的DateTimeOffset.Now等。

在我的测试中，我应该使用类似的东西：

var myDate = new DateTimeOffset(2016, 3, 29, 12, 20, 35, 93, TimeSpan.FromHours(-3));

或者我会使用像MyCustomDateTimeOffset这样的包装类？ 我的代码中根本不应该使用DateTimeOffset而是使用包装器吗？

I would appreciate information or examples about how to correctly test code that uses DateTimeOffset instances. I know the tests have to be deterministic.

So, how would one isolate the application from the DateTimeOffset classes ? I would, of course, like to be able to use a fake DateTimeOffset.Now, etc.

In my tests, should I be using something like:

var myDate = new DateTimeOffset(2016, 3, 29, 12, 20, 35, 93, TimeSpan.FromHours(-3));

Or would I instead be using a wrapper class like MyCustomDateTimeOffset ? Should I not use DateTimeOffset at all in my code and use a wrapper instead?

最满意答案

正如基本面定理所说：

我们可以通过引入额外的间接级别来解决任何问题。

你真的不需要一个包装器，你只需要避免使用DateTimeOffset.Now / DateTimeOffset.UtcNow 。

以下是您可以处理的几种方法：

如果使用依赖注入，请编写一个公开Now / UtcNow属性的IClock接口。

public interface IClock { DateTimeOffset Now { get; } DateTimeOffset UtcNow { get; } } internal class Clock : IClock { public DateTimeOffset Now => DateTimeOffset.Now; public DateTimeOffset UtcNow => DateTimeOffset.UtcNow; }

在您的测试中，您只需按照自己的意愿模拟界面。

如果你宁愿继续使用静态属性，写一个静态类型，比如说Clock ，然后使用它。

public static class Clock { internal static Func<DateTimeOffset> DateTimeOffsetProvider { get; set; } = () => DateTimeOffset.Now; public static DateTimeOffset Now => DateTimeOffsetProvider(); public static DateTimeOffset UtcNow => DateTimeOffsetProvider().ToUniversalTime(); }

在测试中，您可以替换DateTimeOffsetProvider 。

这是一个.NET 2版本：

public static class Clock { internal delegate DateTimeOffset DateTimeOffsetProviderDelegate(); internal static DateTimeOffsetProviderDelegate DateTimeOffsetProvider { get; set; } public static DateTimeOffset Now { get { return DateTimeOffsetProvider(); } } public static DateTimeOffset UtcNow { get { return DateTimeOffsetProvider().ToUniversalTime(); } } static Clock() { DateTimeOffsetProvider = delegate() { return DateTimeOffset.Now; }; } }

As the fundamentals theorem says:

We can solve any problem by introducing an extra level of indirection.

You don't really need a wrapper, all you need is to avoid DateTimeOffset.Now/DateTimeOffset.UtcNow.

Here are a few ways you could handle that:

If you use dependency injection, write an IClock interface which exposes the Now/UtcNow properties.

public interface IClock { DateTimeOffset Now { get; } DateTimeOffset UtcNow { get; } } internal class Clock : IClock { public DateTimeOffset Now => DateTimeOffset.Now; public DateTimeOffset UtcNow => DateTimeOffset.UtcNow; }

In your tests, you just mock the interface as you wish.

If you'd rather keep using a static property, write a static type, let's say Clock, and use that.

public static class Clock { internal static Func<DateTimeOffset> DateTimeOffsetProvider { get; set; } = () => DateTimeOffset.Now; public static DateTimeOffset Now => DateTimeOffsetProvider(); public static DateTimeOffset UtcNow => DateTimeOffsetProvider().ToUniversalTime(); }

In your tests, you can substitute DateTimeOffsetProvider.

Here's a .NET 2 version:

public static class Clock { internal delegate DateTimeOffset DateTimeOffsetProviderDelegate(); internal static DateTimeOffsetProviderDelegate DateTimeOffsetProvider { get; set; } public static DateTimeOffset Now { get { return DateTimeOffsetProvider(); } } public static DateTimeOffset UtcNow { get { return DateTimeOffsetProvider().ToUniversalTime(); } } static Clock() { DateTimeOffsetProvider = delegate() { return DateTimeOffset.Now; }; } }