Because we’re not completely insane, we run automated testing of the web sites and web-based applications we develop. Because we are busy, we probably don’t do as much testing as we’d like. While there’s always room for improvement, though, having both unit tests and functional tests is a huge, huge win.
For enterprise intranet sites, there are a lot of things which are time-based. There are documents that get published or expired on given dates, users who receive notifications on a schedule, financial tables that depend on the fiscal year, and so on. If you test these functions (and, of course, you do), you may discover your automated tests suddenly fail on the first day of the quarter or some other threshold. This will likely be due to hard-coded dates in your test fixtures (and surely not because of boundary-condition bugs in your code).
There is an easy solution. Where it’s appropriate, you can make your fixtures “smart” by using adaptive logic. Messy, beautiful functions like PHP’s strtotime make this easy.
For example, here’s a snippet from a fixture for a Yii-based project. It’s for a message data table, and I want to be able to guarantee that there’s at least one valid message and one expired message no matter when I’m testing:
"Content"=>"There will be an important announcement on ".date('m/d/Y',strtotime('first day of next month')),
"PublicationDate"=>date('Y-m-d H:i:s',strtotime('midnight first day of last month')),
"ExpirationDate"=>date('Y-m-d H:i:s',strtotime('midnight first day of next month -1 second')),
"Content"=>"This message is never current",
"PublicationDate"=>date('Y-m-d H:i:s',strtotime('midnight first day of last month -2 month')),
"ExpirationDate"=>date('Y-m-d H:i:s',strtotime('midnight first day of this month -1 day')),
With a fixture like that, I can make safe assumptions about time-related displays no matter what the current date is.