http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Ayende, I might be too sleepy while reading this but the approach with the "Using" block (that Tuna mentions) ensures that unit tests clear up the DateTime they set for testing in the Dispose() back to DateTime.Now. In your case you would have to use a teardown or set it back explicitly. http://ayende.com/3408/dealing-with-time-in-tests#comment14http://ayende.com/3408/dealing-with-time-in-tests#comment14Thu, 31 Jul 2008 19:22:36 GMTGreg, you can easily add a "readOnly" flag to SystemTime and allow for modifying Now only in case "readOnly" is false. For testing purposes you can change "readOnly" in your fixture setup. Thus working around this guard would be quite obvious in the code and requires extra effort by a developer. http://ayende.com/3408/dealing-with-time-in-tests#comment13http://ayende.com/3408/dealing-with-time-in-tests#comment13Tue, 15 Jul 2008 05:45:34 GMTGreg, I don't. It doesn't make sense to do it for production. I am not trying to verify that people can't do stupid stuff http://ayende.com/3408/dealing-with-time-in-tests#comment12http://ayende.com/3408/dealing-with-time-in-tests#comment12Fri, 11 Jul 2008 08:39:11 GMTSo how do you test that some production code doesn't accidentally do something like: SystemTime.Now = () => someFixedDate; Having a read/write property for the time is dangerous if you depend on it to make decisions. And it's virtually impossible to test that you're not doing something like this anywhere it a system. http://ayende.com/3408/dealing-with-time-in-tests#comment11http://ayende.com/3408/dealing-with-time-in-tests#comment11Fri, 11 Jul 2008 07:29:15 GMTPff, And there was me calling kernel32.SetLocalTime for such tests. ;) Thanks for the approach! http://ayende.com/3408/dealing-with-time-in-tests#comment10http://ayende.com/3408/dealing-with-time-in-tests#comment10Tue, 08 Jul 2008 12:50:20 GMTTuna, My way is three lines of code, that is it. http://ayende.com/3408/dealing-with-time-in-tests#comment9http://ayende.com/3408/dealing-with-time-in-tests#comment9Mon, 07 Jul 2008 19:47:58 GMTThis is not something that you'll likely change for production, it is needed for tests only. It is also something that I _want_ to be cross threaded, I have mutli threaded tests http://ayende.com/3408/dealing-with-time-in-tests#comment8http://ayende.com/3408/dealing-with-time-in-tests#comment8Mon, 07 Jul 2008 19:38:30 GMTWhy wouldn't you go for abstraction? The simplicity? I think that this would be more readable and maybe elegant? using(IDisposable time=Time.Frozen("11.11.2011")) { } http://ayende.com/3408/dealing-with-time-in-tests#comment7http://ayende.com/3408/dealing-with-time-in-tests#comment7Mon, 07 Jul 2008 16:25:54 GMTThe problem with not doing a full injectionable implementation (i.e. some IDateTime interface, etc.) is that you're now coupled to a different class. While this new class is more flexible, it's not thread safe--one thread could change the Now delegate and affect all other threads using SystemTime.Now. http://ayende.com/3408/dealing-with-time-in-tests#comment6http://ayende.com/3408/dealing-with-time-in-tests#comment6Mon, 07 Jul 2008 12:57:12 GMTBecause it is a field that contains a delegate. That allows me to directly switch values without needs to stub it. http://ayende.com/3408/dealing-with-time-in-tests#comment5http://ayende.com/3408/dealing-with-time-in-tests#comment5Mon, 07 Jul 2008 10:32:06 GMTI've seen IClock.GetCurrentTime in the codecampserver source. Easy to stub / mock with a class that allows you to specify a time. I curious as to why you needed to pull out the Func-y lambda magic just to set a static property here? http://ayende.com/3408/dealing-with-time-in-tests#comment4http://ayende.com/3408/dealing-with-time-in-tests#comment4Mon, 07 Jul 2008 10:16:49 GMTI don't try to enforce that. The tests will make sure that this happen, because if there is time used there, it will be tested, and for that you need SystemTime. http://ayende.com/3408/dealing-with-time-in-tests#comment3http://ayende.com/3408/dealing-with-time-in-tests#comment3Mon, 07 Jul 2008 06:15:42 GMTThis solution seems to be the most effective way to get reliable tests if there are timing issues involved - We found this out the hard way, a lot of what our products do are timing sensitive, and require actions like backing off for X amount of time, scheduling Y to occur after Z amount of time has elapsed. Steve - You could probably use aspects in your debug builds to intercept calls to DateTime.Now, and throw exceptions if that is the case. http://ayende.com/3408/dealing-with-time-in-tests#comment2http://ayende.com/3408/dealing-with-time-in-tests#comment2Mon, 07 Jul 2008 06:07:47 GMTI guess this is similar to introducing a mockable IClock dependency which I have done in the past to time sensitive services. Just curious, how do you enforce that you use the SystemTime in the actual implementation when required instead of absent-mindedly reverting to DateTime? http://ayende.com/3408/dealing-with-time-in-tests#comment1http://ayende.com/3408/dealing-with-time-in-tests#comment1Mon, 07 Jul 2008 05:52:13 GMT