Beware Calculations in Unit Tests

Today our project’s continuous integration build failed.  I traced it down to a unit test that was exercising a scheduling class.  The class takes a schedule and figures out the next time it should run based on the current date. 

Now in our project we’ve provided a way to stub the current date or current time by having a SystemClock class that has a static Instance property.  If we need to we can push a stubbed instance into that property in a unit test to control what the current date/time is.

The problem in the unit test was that it was relying on DateTime.Now and then figuring out what the expected next scheduled time should be right in the unit test.  The calculations were wrong in the unit test and caused the unit test to fail.

Almost every time I see calculations in unit tests to figure out what the expected value should be (especially date-based calculations) I cringe because I see those as unit tests waiting to fail.  If you’ve copied your calculations from the class under test, who says you got the calculations right in the production class?  If you did the calculations differently, your unit test’s calculations could be wrong.  Wherever possible I prefer to keep the moving parts to a minimum and have constant dates as my expected values in date-based unit tests.