Term of the Day: Principle Of Least Surprise – Epilogue

Okay, this is funny.  Little did I know that while writing “Term of the Day: Principle Of Least Surprise” I was entering the midst of just such a problem.

The entry was written over a 2-3 hour span during compile waits on various tasks.  The last hour or so required debugging due to some really strange behavior.  I was working at the persistence layer on a data mapper responsible for persisting a complex object, adding support for new composite type that was a few levels down in the object model.  Everything looked right, but for some reason my tests kept failing.   I finally had to debug and intercept the SQL that was generated to see what was going on. 

In the end I found the problem in a class that I wasn’t using directly that was providing the table name.  This is okay and common in our persistence framework.  What was not okay was that it specified the target database along with the table name, ignoring the connection information that was passed back to the data mapper.  The mapper was saving data to the correct database, but was retrieving it from another database.  I took out notwhatiwant.dbo from the const defining the table name and ran my tests again…some other tests on code that I wasn’t working on started to fail.  It didn’t take too long to clean everything up after that, but it was annoying.

…lol, told you it wasn’t that uncommon

P.S.  This is also a great argument for automated unit tests.  Resolving this was only quick because of over 5,000 automated unit tests that cover our code.  The tests that broke relate to the code base from a separate subsystem that I wasn’t even working on.  The need that prompted the addition of the database name to the tableName constant was addressed implicitly and in such a way that limited reuse.  Without the tests I probably would have ended up deploying a new bug.  We have great tests…that’s why we rock.