Unit testing code that does date processing based on today's date - unit-testing

Question

When code processes dates based on the current date, testing should cover edge cases such as leap years as well as the more frequent month and year boundaries.
In our code we always get the current date deep down in our classes using DateTime.Now (.NET, in our case).
How can you unit test such code?
Is this where Dependency Injection becomes very useful?
Edit
This is a slight aside, but apparently the next version of Typemock will allow faking of DateTime.Now
https://blog.typemock.com/2009/05/mockingfaking-datetimenow-in-unit-tests.html

Answer 1

In our code we always pull out the current date using DateTime.Now (.NET, in our case). How can you unit test such code?
This is a dependency, and a non-deterministic dependency at that. You need to divide the responsibility of the code up a little more.
Before:
There is some code that uses the current datetime to do X.
After:
There should be some code that is responsible for getting the current datetime.
There should be some code that uses a datetime to do X.
These two sets of code should not be dependent on each other.
This pattern of seperating dependencies works for other cases as well (database, filesystem, etc).

Answer 2

Using DI for injecting "Current Date & Time" is surely an overkill. I'd rather refactor the code to operate on arbitrary date. That is, I'd change function calculateRevenue() to function calculateRevenueOn(datetime date). This is much easier to test and use in case you need calculation for some dates other than current.

Answer 3

I've used the very pragmatic approach discussed by Oren Eini (aka Ayende Rahien) in his blogspots Dealing with time in tests.
There is a static class like this:
public static class SystemTime
{
public static Func<DateTime> Now = () => DateTime.Now;
}
Your code becomes:
Entity.LastChange = SystemTime.Now();
And your test would become:
SystemTime.Now = () => new DateTime(2000,1,1);
repository.ResetFailures(failedMsgs);
SystemTime.Now = () => new DateTime(2000,1,2);
var msgs = repository.GetAllReadyMessages();
Assert.AreEqual(2, msgs.Length);

Answer 4

Always put the core date processing logic (which is, in my experience, usually easy to isolate for this purpose) into separate methods that take the date as a parameter.
Then, in your production code you can call those and give them the current date as parameter, and still test edge cases to your heart's content in unit tests.
BTW, I've found it quite crucial to test date logic very intensively for edge cases. It eliminates (possibly catastrophic, ref. Zune) bugs that you'd never have found otherwise. Apart from the ones you mentioned, daylight savings time switches can also be problematic.

Answer 5

You already gave the answer. You can write a small wrapper class around datetime functions that you can then inject in the classes that need to get the current date. Replacing DateTime.Now with a call to your wrapper object.
In your tests you can then inject a stub or mock object that gives you the date you need.
Another solution might be, depending on how your code works, just pass the date as a parameter instead of burying calls to datetime.Now. This makes your code a bit more reusable because it can work on more than the current date

Answer 6

public interface ITimeProvider {
DateTime Now { get; }
}
public class SystemTimeProvider : ITimeProvider {
public virtual DateTime Now { get { return DateTime.Now; } }
}
public class MockTimeProvider : ITimeProvider {
public virtual DateTime Now { get; set; }
}
public class ServiceThatDependsOnTime {
protected virtual ITimeProvider { get; set; }
public ServiceThatDependsOnTime(ITimeProvider timeProvider) {
TimeProvider = timeProvider;
}
public virtual void DoSomeTimeDependentOperation() {
var now = TimeProvider.Now;
//use 'now' in some complex processing.
}
}
[Test]
public virtual void TestTheService() {
var time = new MockTimeProvider();
time.Now = DateTime.Now.AddDays(-500);
var service = new ServiceThatDependsOnTime(time);
service.DoSomeTimeDependentOperation();
//check that the service did it right.
}

Answer 7

you could make a mockobject that simulates the DateTime.Now
here is article with an example where DateTime.Now is being mocked: Link

Answer 8

Dependency injection can be a solution for this, yes.
What you will do is create, for example, an IDateTimeProvider interface with a method: GetDate(). In your production-code class you will implement return DateTime.Now.
When unit testing, as Natrium suggested, you can then replace this with a mock object, one that returns a certain date to test on.

Answer 9

Why not use Fakes? With Visual Studio is as easy as possible. Just add a fake assembly to System, add the ShimsContext to your test,
using (ShimsContext.Create())
{
And set the DateTime.Now to return a specific value:
System.Fakes.ShimDateTime.NowGet = () => new DateTime(2000, 1, 1);
This approach makes sure every call to DateTime.Now is redirected to your code, so you don't have to inject anything to get the current time (which should be really straightfoward) nor you need a global, writable, variable.