|
|
|
|
|
by hinkley
2007 days ago
|
|
The worst thing to deal with in regard to determining correctness of code is global, shared, mutable state. Timestamps fit that bill (even though it's the Universe changing the state). For testing purposes I often find myself making functions that take the date as an argument. If the language supports default values, I'll set it as a default value. If it doesn't, I'll make a convenience method or a null check to set it to 'now' if none is provided. It turns out though that a lot of code we write to run within ±30 seconds of 'now' ends up over time having to run (or re-run) on old or future dates. So with the exception of logging and events, having that as an argument turns out to be useful or at least neutral. For logging and events I'd probably use a mock timing library anyway. |
|