I think TDD is only done correctly if unit tests are black box. You write your tests and thereby define your interface, regardless of the implementation behind it. Once you get to the refactoring stage you (may) change your implementation to make your code better organized|more efficient|less redundant|etc. Your refactoring succeeds if you manage to change your implementation without breaking a test. If you then have code that's not being tested, you have one of two cases
- Your tests don't accurately describe your interface, because you forgot to test for an outcome that should be part of your spec.
- The untested code should be removed because it produces an outcome not included in the spec (because ideally your tests are the most thorough description of the spec)
In the case of 1. you need to add a test, but you still want to test against the module interface, not against the particular implementation. This is a corner case where you're actually finding a better interface by coincidence while refactoring. If you're writing your tests correctly it shouldn't happen (though IRL it does).
I do agree that it takes a special sort of mindset to properly separate your test-writing brain from your implementing brain, so that's a practical problem for all but the schizophrenics among us :-).