Brian Duff gives a good example of a technique to get around visibility problems when unit testing. Believe it or not, this can be a good idea (and this is a strong TDD advocate saying this).
When using unit tests to drive your design, as in TDD, it would be a seriously bad idea to test private methods, or anything else that is overly implementation specific. It makes the tests to fragile, and will cause problems when it comes time to refactor the design. However, as the saying goes: TDD is about design, not about testing. Sometimes you do need implementation-oriented tests.
In this case, the rules for unit testing for TDD just don't apply; new rules come into play. Sometimes you can't tweak the API. Other times, you may not even be able to change the source; for example, when it's a feature, not a bug. :) Other times, it just may not be aethestically pleasing to do so.
Personally, in Brian's case, I would have extracted an interface for clients to use that matched what I wanted, and
then made the necessary test points public, but that's my style in a given situation, and each to their own.
Unit testing privates does have its place in verifying the implementation; just don't use it to do TDD.
