This is an addition to TestingPatterns (we might need a CategoryTestingPatterns?).
Also see TestOverridesNow.
Some time ago I proposed a "Virtual Clock" pattern on the XP mailing list. I was encouraged by KentBeck to write it down, and at long last I did.
The original document Paolo refers to is not available, but he was able to send me a Ruby version he also authored.
The original document feel off the Internet.
Nice. I do the same thing, only different. :) I create Time interface, and then provide either RealTime implementation, or a MockTime? implementation. This gives me flexibility to advance the time any amount at any time (or not), but because MockTime? is *only* referenced from test code, it avoids the "accidental freezing" you mentioned.
-- DavidCorbinYou're right, this is a better approach. The code in 1.0 uses this --PaoloPerrotta
You can refer to ThePrevayler to see another use of a "virtual clock". Klaus' AlarmClock? prevents nondeterminstic behavior in the face of commands that depend on the system clock.