The downside of SystemTime

I’ve always been a fan of the elegance of Ayende’s SystemTime approach to dealing with time in tests. Unfortunately, I’ve recently re-discovered the problems that come with using globals.

I had a dependency on two different projects, each of which declared their own instance of SystemTime. Not insurmountable, as they were namespaced, but annoying and confusing nonetheless.

So from now on, for me, the new One True Way is just to pass in a Func<DateTime> as a constructor dependency:

public class Frobulator
    public Frobulator(Func<DateTime> currentTime)
        this.currentTime = currentTime;

    public DateTime Frobulate()
        return currentTime();

public class FrobulatorTests
    public void Frobulator_should_use_current_time()
        var juanRodriguezCabrilloDiscoversCaliforniaAtSanDiegoBay = new DateTime(1542, 9, 28);
        var frobulator = new Frobulator(() => juanRodriguezCabrilloDiscoversCaliforniaAtSanDiegoBay);

        var dateTime = frobulator.Frobulate();

        Assert.That(dateTime, Is.EqualTo(juanRodriguezCabrilloDiscoversCaliforniaAtSanDiegoBay));

One thought on “The downside of SystemTime

  1. Khalid Chatar January 17, 2013 / 4:49 pm

    Hi Graham,

    how about Property-Injection with default Func instead. This way you have the desired default behaviour without effort, yet being able to change it when testing.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s