Comments on: Testability Of Date-Dependent Code

By: Testing Time—Static Calls and ISystemTime

Testing Time—Static Calls and ISystemTime — Fri, 06 May 2011 02:37:31 +0000

[...] Davy Brion linked to my previous article on this subject. In the comments for Davy’s post, Mel Grubb linked [...]

By: Davy Brion

Davy Brion — Fri, 23 Oct 2009 06:03:47 +0000

@Eric

we don’t run multiple tests simultaneously so it works… and like i said “And as long as that works, resist the urge to change it.”

once it stops working (like when switching to a multi threaded testrun) then you obviously change it

By: Eric Smith

Eric Smith — Fri, 23 Oct 2009 05:04:22 +0000

Great idea – just one problem—you can’t run multiple tests simultaneous in separate threads. How about a [ThreadStatic] dateTimeToReturn?

By: SeeR

SeeR — Wed, 21 Oct 2009 22:39:09 +0000

This is what I’m using

public class SomeClass { public static Func Now = () => DateTime.Now;

public void SomeMethod() { ... var x = Now().Hour; ... } }

And than I just setup SomeClass.Now in each of my tests

By: Jonathan Oliver

Jonathan Oliver — Wed, 21 Oct 2009 15:39:11 +0000

One point I’d like to mention is that of using IDisposable to ensure that the correct/real DateTime is restored at the end of your operational context. Since posting my original article, I have create written another one introducing some open source code to address this very issue:
http://jonathan-oliver.blogspot.com/2009/10/testing-timestatic-calls-and.html

It’s very similar to Mel Grubb’s approach (which I have become aware of because of his comment above), the difference being that my approach stores the DateTime object on the thread-local store rather than DateTimeContext.

By: Mel Grubb

Mel Grubb — Wed, 21 Oct 2009 15:27:53 +0000

Here’s a third variation for you using a nestable, thread-local-storage-based “context” class.
http://melgrubb.spaces.live.com/blog/cns!A44BB98A805C8996!263.entry

The implementation may be more “overkill”, but it makes the usage nice and simple.

By: Shawn Neal

Shawn Neal — Wed, 21 Oct 2009 14:55:09 +0000

A DateTime service is overkill for most scenarios. We do EXACTLY what you’re doing with your DateTimeProvider, works like a champ. I’m just waiting for someone to write a test that forgets to reset the time provider, but that hasn’t happened yet.

By: KG2V

KG2V — Wed, 21 Oct 2009 13:57:49 +0000

For years, I’ve just gone the other way – Datetime is a passed parameter

By: Davy Brion

Davy Brion — Wed, 21 Oct 2009 13:34:53 +0000

@Urs

did you read the first part of the post?

By: Urs Enzler

Urs Enzler — Wed, 21 Oct 2009 13:29:39 +0000

Furthermore, I would suggest to not use a singleton but pass the service to its client with dependency injection.

By: Mike

Mike — Wed, 21 Oct 2009 09:53:16 +0000

I posted about this topic a while back http://journalofasoftwaredev.wordpress.com/2009/01/31/obstacles-of-unit-testing-methods-to-side-step-them-part-1-date-and-time/ using this technique it also mentions the Ayende method Karsten has linked to above. Once I get some time I should finish the rest of series off!

By: Davy Brion

Davy Brion — Wed, 21 Oct 2009 09:36:01 +0000

the performance cost that comes with this level of indirection will definitely not be noticable. Even if you’ve got iterations of millions, you won’t notice this compared to _other_ performance penalties that you most likely will notice when dealing with that kind of volume.

or put differently: if you’re dealing with millions of records and you notice a difference because of this trick, then i will very gladly tip my hat to you sir

By: Stefano Ricciardi

Stefano Ricciardi — Wed, 21 Oct 2009 09:20:03 +0000

This looks like a nice trick. Have you noticed any run-time penalties due to this level of indirection?

I am considering scenarios like bulking thousands (if not millions) of records where the the current time is used as a part of the key.

By: Karsten

Karsten — Wed, 21 Oct 2009 08:23:16 +0000

Ayende uses a variation of the same technique: http://ayende.com/Blog/archive/2008/07/07/Dealing-with-time-in-tests.aspx

By: Reflective Perspective - Chris Alcock » The Morning Brew #459

Reflective Perspective - Chris Alcock » The Morning Brew #459 — Wed, 21 Oct 2009 07:25:44 +0000

[...] Testability Of Date-Dependent Code – Davy Brion talks about two common techniques to enable the reliable testing of Date based code either by providing the date obtaining routine with a service which can be overridden for testing, or by routing all calls for dates through a custom static method which can be provided with dates to return [...]

By: Andrey Titov

Andrey Titov — Wed, 21 Oct 2009 05:52:35 +0000

I’ve seen a code that relies on two subsequent DateTime.Now calls returns the same value. I don’t remember how it exactly looks, but it was something like this:
if(IsPaidHour(DateTime.Now))
{
price = GetCurrentPrice();
}
else
{
price = 0;
}

and GetCurrentPrice() also calls DateTime.Now and throws if called in a wrong time.

So since that I count calls to DateTimeService.