a couple of my testing rigs depend on conditional compilation code which is internal – it's pretty much necessary to access all the internal variables. And the overall code is so complex that without that you'd never know what was wrong.

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.

The accessibility thing bothers me, too. Someone needs to hack our respective languages and create a new accessibility modifier for “public, but only for testing robots. Otherwise private”.

(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: )

Yep, I completely agree.

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.