Your automated test suites are working as you'd expect, then one day BAM! The build breaks for a mysterious reason, sometimes even without a change to the source. Upon further investigation, you find out that some test somewhere had made some assumption about the date.

No, you won't need an oracle or a tricked-out DeLorean to peer into the future. It turns out you're already using a great tool for simulating time travel. Just about everyone I've spoken with who's written automated tests has had this problem at one time or another (including me):

Your automated test suites are working as you'd expect, then one day BAM! The build breaks for a mysterious reason, sometimes even without a change to the source. Upon further investigation, you find out that some test somewhere had made some assumption about the date. It's not usually an assumption about what today is since those errors get flushed out pretty quickly - usually a day after they're written. These types of failures are usually aligned to important dates in the business domain, such as after January 1st, after the start of a quarter, or April 15th (the date U.S. taxes are due).

To try to catch these failures when you write the tests (when it's cheapest to diagnose), try rolling your computer's system clock forward and re-running the test. How far forward you decide to go usually depends upon the application, but it's probably safe to turn your system clock forward at least one year. If your tests fail, you've got some hidden assumption about the date in your code, whether it's in the test code or even the production code.

To solve any problems that appear, you might try making the test declare what "today" is, so it's made explicit for future test readers. Then look for setup of other test data, keeping an eye out for fixed years, and make sure the dates make sense compared to your introduced value for "today". If it turns out that the exact dates aren't really important, try using the "Generated Value" pattern as described in Gerard Meszaros's "xUnit Testing Patterns" to make the intent cleaner for test readers.

In fact, tools like ScalaCheck (for the Scala language) or QuickCheck (for the Haskell language) can generate several dates for you automatically. Check out these tools for a new way to think about generating test data and testing algorithms.

About the author

Daniel Wellman is a technical lead at Cyrus Innovation, a leading agile consultancy based in New York, where he leads development projects and coaches teams on adopting agile software development practices. Daniel has more than ten years of experience building software systems and is an expert in agile methodologies, object-oriented design, and test-driven development. Contact Daniel at dan@danielwellman.com.