tags:

views:

66

answers:

2

Currently I'm writing a unit test for a component that does datetime specific validation. I have created IDateTimeProvider interface, that serves as a DateTime.UtcNow wraper and business objects use interface rather than DateTime directly. It seems that DateTime is a bit overloaded and should be split into a value and a thing that gets that value from the OS. I wonder if there is a particular reason not to have a IDateTimeProvider (IClock) interface in .NET?

+4  A: 

Simply put: because large parts of the BCL weren't designed for testability.

The same is true for random number generation, in terms of "core" functionality - and a lot of the HTTP-related classes are much worse to fake out :( At least in this case it's reasonably easy to introduce your own clock interface.

On the plus side, when Noda Time is ready for production use, it will not only provide a better date/time API than the BCL - it'll provide a more test-friendly one :)

Jon Skeet
+1  A: 

We consistently use a DateTimeProvider wrapper class which we can override in a test context if necessary...

Koen