>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.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s