MockingFaking DateTime.Now in unit tests

A sneak preview of what’s coming in Isolator’s next version:

image

Yep. You’ll be able to fake DateTime.Now!

The test above already passes on my dev machine. Soon, you’ll be able to have it too. Watch for a release with this feature in the coming weeks.

Try Typemock Isolator Complete FREE for 15 days, and once the trial is over, Typemock Isolator Basic will remain yours forever!

  • Soon Hui

    Great! Does this mean that we can now fake mscorlib?

  • Slace

    Hmm interesting, since DateTime is part of mscorlib which we were always told was unmockable…

    But I do question to value of doing this. Essentially you’re making a type which has an expectation to change on every call (basically) but it’s no longer changing. To me that makes it seem like the test is pointless as it’s not really testing the operation under real circumstances, only contrived ones.

  • Gil Zilberfeld

    We never said it’s unmockable. But it was until now :)

    Soon Hui – Faking mscorlib is taking it step by step. And DateTime is the first type we handled.

    Slace – Out of all the requests we get, faking DateTime.Now is the loudest. Obviously the test in this post is only for presenting the point. Many people have tests that have logic relying on the current date and time (e.g. what to do in case of expiration date). The only way to test that today is to move the computer clock forward and backwards.Tests relying on the date/time will give you different results every time you run them.

    Now with this ability you can write reliable tests based on the time, without changing your clock or production code.

  • Slace

    Ahh I see your point now Gil, and I’m surprised I didn’t realise that myself :(

    I guess that one thing I keep forgetting is that Typemock blurs the line between mocking and faking.
    True TDD would probably state that you pass in the date to your method, or that you have a “factory” which returns you the date, rather than directly accessing the DateTime struct.

    But when you get into that level of abstraction you end up with absolutely nothing but custom objects and factories in your code just so your can feel all warm and fuzzy and saying “I’m pure TDD” :P

  • Gil Zilberfeld

    Slace -

    Whenever I hear “pure” I sense something is wrong :)

  • Slace

    My point exactly. Now if only I could sneek a peak at the Isolator source… ;)

  • Joe Mamma

    Uh, yeah sign me up for that webcast… ;)

  • Mel

    Interesting. I posted a slightly lower-tech solution to this a while back that should work with any mocking framework. (http://melgrubb.spaces.live.com/blog/cns!A44BB98A805C8996!263.entry)

    The difference being that only code that was put into a “using DateTimeContext” block would be affected. It seems a little safer to me since only code I explicitly allow to be lied to can be.

  • Arthur

    I am curious what effect the Daylight Saving Time rule has on the resulted date/time?

  • ulu

    Ah, at last!!!

    I agree that putting the system clock behind an interface could be a good idea in a project with lots of time-related stuff, but doing it just for a single call is a huge overkill.

TOP