I think it’s important to understand when hacking code in is going to hurt us and quite often I think the side effects of taking this approach are underestimated. Tom spoke of 'value fetishism' whereby we get so caught up trying to add 'business value' that we forget to keep the code in good stead for future work. I quite like the analogy that Alistair Cockburn uses of software development as a series of cooperative gamem and I think it’s sometimes easy to forget in the rush to get some code out for a release that we have to make sure that we don’t make our lives impossible for the next game/release by rushing code in without paying due attention.

The cleanest solution for that second point is to move those methods out into their own class where we could test against them directly. A smaller step to take is to make the method protected and then create a test version of the class from which we can call the protected method directly. Feathers also talks about the danger of using reflection to allow us to test this kind of code - it might allow us to get tests around the code but we’re not making the code any better and we may not notice quite how bad the code has got. We are just delaying the inevitable. There’s a tool in .NET land called TypeMock which allows you to test pretty much anything but I wonder whether we would run into the same problems that Feathers describes above.