If you’ve been reading the Shade Tree Developer this week you’ll know that I’m fighting with a legacy component. I was trying to get a piece of code into NUnit to test my new functionality. A class in the stack works by giving it a key value to a record in the database. I tried for awhile to use an existing stored procedure to push in test data. Guess what I found? I had relational integrity issues with setting up the test data, but so what, that’s just what a database is. I wasted a bit of time pushing past the referential integrity by getting the correct data and stumble right into security authorization being performed inside the f***ing stored procedure!
It was about this time I remembered what I had been reading in the Feathers book on legacy code. Sometimes you have to change the code just to get it into the test harness. A quick “CTRL-ALT-M” action with ReSharper, and voila, an entry point into the business logic that bypasses the database and security checks. Add some ObjectMother magic to construct the fugly data structures, and I’ve got a working unit-ish test.
Moral of the story? Don’t be afraid to change the code first before writing a test (well, maybe afraid but not terrified). Remembering to backup and look for an easier way to write a test was probably a good idea too.