"A" way of dealing with dates in automated tests

maybe I am being naive here, but couldn’t you just pass the DateTime (now) as a parameter to the constructor of the object under test? then in production code pass DateTime.Now but in your test pass the hard coded value to verify your business logic?

I like the clock interface myself… Especially if the interface can provide some meaningful operations that keep DateTime/TimeSpan arithmetic out of components.

This one’s geared more for background task intervals, but you get the idea.

public class TestClock : IClock
{
private DateTime _now = new DateTime(1971, 10, 14, 12, 34, 56);

DateTime IClock.GetOffsetMoment(TimeSpan offset)
{ return _now.Add(offset); }

bool IClock.HasMomentArrived(DateTime moment)
{ return moment <= _now; }

public void Advance(TimeSpan offset)
{ _now = _now.Add(offset); }
}

Assert.That(entry.Status, Is.EqualTo(TaskStatus.Idle));
_clock.Advance(TimeSpan.FromSeconds(25));
Assert.That(entry.Status, Is.EqualTo(TaskStatus.Idle));
_clock.Advance(TimeSpan.FromMinutes(3));
Assert.That(entry.Status, Is.EqualTo(TaskStatus.Pending));

Interesting post!
The approach I’ve had the most success with is definitely alternative 1.

What I usually do though is not assign some arbitrary time to use as a baseline but instead wrap DateTime.Now and freeze the now moment.

Something like this is usually what it looks like:

[SetUp]
public void Setup(){
TimeWarper.Now = DateTime.Now; //Freeze time!
}

[Test]
public void TestSomething(){
…
//myThing uses TimeWarper.Now internally
myThing.DoStuffInvolvingTime(48);

Assert.AreEqual(TimeWarper.Now.AddDays(2).ToString(), myThing.FutureDate.ToString());
}

This has the advantage of not caring what the absolute value of the date is. At the same time doing it with a static override you don’t have to do any special date declarations in your tests, which is great for readability.

As for the case when you forget about using the wrapper, that will hopefully result in a broken test and is easily fixable.

I blogged a bit about it here a while ago:
http://omgwtftdd.blogspot.com/2009/02/testing-datetimenow-introducing-wrap.html

@Jeremy,

It was a joke 😉 I thought the “:P” would give it away. If I ever saw anybody here setting the clock for such reasons I would personaly kick them out of the window.

I like the “TODAY-#” approach. However, from a readability stand point, I would wonder what the -2 in “TODAY-2″ actually means. It could also be weeks, months or whatever. Especially since I would also like a NOW, and “NOW-4″ could mean even more things.

I think “NOW-2h”, or “NOW-04:33:10.123″ would be nice.

@Kent,

It would I believe, but as in almost all proposed uses of TypeMock I’d have to ask if it actually was a good idea to retreat to TypeMock.

You’d still have the test readability issue with that.

I don’t agree that you’re stuck with problem (b) if you adopt approach #1.

The hard-wired date value used by the dummy clock for “today” is (should be!) available for testers to write something fairly readable so that they don’t have to unreadably hard-wire a particular date that’s “known” to be 7 days from “now”. But never hard-wired dates that require the reader to parse.

So in a C# nunit test class, you might see something like “MyTest.Today.AddDays(7)”; or in xml config you might see something like your StoryTeller example.

Hmmm I haven’t looked at StoryTeller yet, so I don’t know for sure. But I do remember someone shouting out something about “Is XML dead yet”, but by the looks of it I would say no

Good read other wise.

-Mark

Sometimes you need IClock because relative dates/times won’t do. I’ve worked on systems where you can only enter new invoices during normal business hours (unless you’re a manager); or you receive a discount on weekends and holidays; or some other business logic dependent on particular dates/times rather than relative. You then need IClock to make the system reliably testable. Otherwise you’ll have spurious test failures if you happen to be working late.