Sometimes, you might want to peek under the hood

So, another day, another thing unlearned.

Today, I faced a method that wasn’t under test. A private method. A big private method that was buried under a couple of layers of indirection. I could see at least one refactoring that would make it easier to manage – but first I wanted to get it under test.

The test I wrote is straightforward but does pretty much what I decided I wasn’t going to do in the last post: inject stuff to peek under the hood. I wanted to get a handle on the implementation.

Difference? This is legacy code. I want to characterise the behaviour in a test. Enough behaviour to make sure that any refactoring I do isn’t changing that behaviour. I want enough points of reference so that when I refactor the assertions I make on currently private behaviour become assertions on public behaviour.

Hmm: determining whether you should use existing implementation behaviour as a way of guiding your refactoring is probably worth a discussion in itself.

Anyhow: in my previous post I was talking about new code. Code where your tests are driving the development, and you don’t need to build up monster private methods, and you can test behaviour using public interfaces, happy in the knowledge that you can ignore any private implementation details.

In the meantime, I think I’m going to carry on examining implementation behaviour if it gives me some confidence in refactoring chunky legacy code.