In order to evoke certain scenarios from your application testing, it is often necessary to make your system think the current time is some point in the past or future. Traditionally, this is done by modifying the Windows system date/time. But a change like this affects ALL applications, not just your own -- with potentially nasty results.
At the heart of this issue is the fact that accessing the property DateTime.Now is typically scattered everywhere across an application's code base. Fetching the value in this manner - explicitly - tightly couples your code to the system clock.
A better way would be to treat the system clock as a separate concern. Instead of accessing DateTime.Now directly, create an interface, called IClock for example, that indirectly retrieves the current time. By using IClock, objects would be loosely coupled to the system clock. In fact, a sophisticated implementation if IClock would allow for the current time to be offset by a certain amount, allowing an application to be tested "in the past" or "in the future", all without having to adjust the actual system time.
No comments:
Post a Comment