I suppose, thinking about it, you could just wrap all the header declarations with conditional statements – then change the compile flags every time you tested.

You're right though, it's ugly & impure.

(I suppose an alternative would be to have unit tests living in the same class as the code they are testing. I dislike it in an architectural purity kind of way d: )

I'm definitely in the “unit testing is a must” camp now. I'm just not sure they're enough

However, I am finding, even going back and writing tests afterwards, that it's making me double (and triple) check all of my logic. Plus, as you point out, tidying up everything at the bottom of the stack, and rethinking flow. It's kindof an enforced code review – which is always helpful.

The only thing I dislike is the requirement to expose so much of the interface in order to test things thoroughly. There's a stack of private methods that are really only pertinent to the inside of any given module that shouldn't be exposed.. and yet have to be. But it's a minor gripe really – particularly considering how sloppy my architecture is generally

(And, well, I like the happy green lights that unit testing tools inevitably show up when everything is working properly <: )

Unit tests, at least, can help you make sure that the little details at the bottom keep on doing what they're supposed to / unit tests which *could* be testing the wrong thing are probably trying to test too much.