[CategoryTesting]

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.

-- PaoloPerrotta

The original document Paolo refers to is not available, but he was able to send me a Ruby version he also authored.

-- BrianEdwards

The original document feel off the Internet.

* ''See: http://web.archive.org/web/*/http://www.nusco.org/docs/virtual_clock.pdf
* Direct link to last download: http://web.archive.org/web/20070221151204/http://www.nusco.org/docs/virtual_clock.pdf''
* Later Ruby version: http://ducktypo.blogspot.it/2013/12/the-virtual-clock-test-pattern.html

-- PaoloPerrotta

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.

-- DavidCorbin

''You'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.

-- JbRainsberger