Brian Hartsock's Blog

A few days ago, a developer at work said something that made me cringe, “Every day we write more legacy code”. My first instinct was to reinstate our corporal punishment policy.

Then he said something quite amazing that I didn’t expect, “Any code we are afraid to change, because it isn’t thoroughly tested, is legacy code.” I cried. Literally.

Figuratively.

I know he read this in Working Effectively with Legacy Code, but to really see him get the importance of testing is awesome.

After hearing a few developers say this book is in their top five, I need to get on the ball and read it myself.

Today I found myself at a crossroads regarding testing. In my efforts to have pure unit tests, I had created tests with no assertions. Each test contained a mock object that verified multiple expectations, but no assertions. While each mock expectation could be thought of as an assertion, is it really a good idea to test the algorithm?

I say no.

The algorithm shouldn’t matter. The only thing that should matter is the input and output of each function.

Now I found my tests are much more stable and not nearly as much of a pain to write. I am setting up my expectations for input and output, but not regarding how to get there.

As you might expect though, the tests aren’t isolated to one class. They cross a few class boundaries, but not layer boundaries.

Have I traded one evil for another? I honestly don’t know, but I am going with my gut, and what makes sense. Having no assertions isn’t right in my opinion. What do you think?