Because of all of the problems I mention above. If you have code paths that aren’t being exercised by a public API, then delete them.

Another point is: if you’re writing private methods up front rather than extracting them from (already tested) public methods, then you’re probably making design decisions too early. If you’re following a TDD approach, you’re writing the simplest thing that works then refactoring later - this would typically involve extracting common code into private methods (to remove duplication or introducing explaining methods) - but the behaviour hasn’t changed and you already have tests in place that go through your public api. At this point, adding direct tests for these extracted private methods gives you nothing; they should already be covered.

Again, as I said before, if you have a large number of private methods that seem to be doing a lot of related things, then extract them into a new class and test that as an isolated unit.

I’m yet to see any convincing arguments as to why you should break encapsulation and test private methods directly but I think I’ve presented numerous reason why you shouldn’t - high coupling between tests and implementation leading to difficult refactoring, obscuring poor design decisions and redundant test code.

Your client code will only be (or should be) using your class under test through it’s public API - your tests should do the same.

You may not exercise the private method via the current class interface, but at a later date you may add another method and you may find an issue in your private method indirectly while testing your new method. I would rather catch the problem with the private code right after writing it than fuddling through an error on an indirect method call a few months later.

Why not test both if you have the luxury?

If you have private methods, test them! If you aren’t testing private methods move them to another class and test that. This is a much better practice and may lead to more reused code.

The fact that you have to jump through hoops to test private methods should tell you that it’s probably not the right thing.

I find this assertion to be completely wrong and bad advice.

It’s not about testing methods, it’s about testing behaviour. Your behaviour should be exercised through it’s public interface (just like your client code) otherwise what’s the point of access control? You should be able to free to refactor the internals of your class (private methods) without breaking anything, including your unit tests. Private methods aren’t behaviour, they are pure implementation detail. As I said before; if you find a lot of stuff happening in your private methods, then maybe there is a hidden class waiting to be extracted. Extract it, then test the new classes public interface.

Remember, refactoring is the process of changing the code without changing it’s behaviour; if you test the code at its lowest level (private methods) instead of testing the behaviour you are testing the wrong thing and creating strong coupling between your tests and your code, making refactoring harder.

Instead of making a method public for testing use instance_eval:

class UserTest “Mike”, :last_name => “Gaffney”)
assert_equal(”Gaffney, Mike”, user.instance_eval {full_name})
end
end

Decide what is the best way for you to know when it is time to refactor.

http://pastie.org/302159