I did a quick google search and noticed that there's a long standing debate on this. I have several questions:
* What are your views on testing private methods and,
* How would you test methods explicitly declared private in PHP5?
* Maybe you should be a bit more discerning before making things private?
Testing Private Methods
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Personally, I wouldn't test private (or protected), methods. Thats an implementation detail. Which I don't think should be enforced via testing. You want to test that the class's public interface meets its spec. So, the private methods should be tested indirectly via testing the public method's interface.
I haven't heard the argument for but it sounds like a very bad idea.
When you refactor, the interface might remain constant while the internals are shuffled around. Testing private methods would interfere with that (ie the test case would have to be edited to keep pace rather than acting as a constant touch stone to guide the refactoring).
I think testing should focus on interfaces. That helps to improve design - encapsulation is what OOP is all about. Testing private methods has got to be evil.
I'm trying to think why anyone would want to. A programmer might have missed the smell of a new responsibility and a need to spawn another class. If methods are rather bloated or there are lots of them you might find it harder to get a fine enough grain against the interface alone. Testing private methods could maybe help to debug something which isn't obvious otherwise. I don't know really. I expect they'll pay for their sins though.
When you refactor, the interface might remain constant while the internals are shuffled around. Testing private methods would interfere with that (ie the test case would have to be edited to keep pace rather than acting as a constant touch stone to guide the refactoring).
I think testing should focus on interfaces. That helps to improve design - encapsulation is what OOP is all about. Testing private methods has got to be evil.
I'm trying to think why anyone would want to. A programmer might have missed the smell of a new responsibility and a need to spawn another class. If methods are rather bloated or there are lots of them you might find it harder to get a fine enough grain against the interface alone. Testing private methods could maybe help to debug something which isn't obvious otherwise. I don't know really. I expect they'll pay for their sins though.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Thank's for your replies. Here's the google search I did: http://www.google.com/search?q=unit%20t ... e%20method and for some strange reason the first two results are anti-private method testing and the second two results are pro-private method testing. I think I'll go no private method testing. 
I had a quick look at one of the links which recommends testing private methods.
The example he gives mentions a sorting algorithm going awry but the failing interface assertions aren't giving enough fine detail to find the problem quickly. That's exactly what I was getting at above: if the algorithm is complex enough for this to be an issue, it probably should be refactored into a new object, with its own fine-grained tests.
Testing smells can be a sign that the design needs a rethink.
The example he gives mentions a sorting algorithm going awry but the failing interface assertions aren't giving enough fine detail to find the problem quickly. That's exactly what I was getting at above: if the algorithm is complex enough for this to be an issue, it probably should be refactored into a new object, with its own fine-grained tests.
Testing smells can be a sign that the design needs a rethink.