I have read the post about how to test private (http://stackoverflow.com/questions/34571/whats-the-best-way-of-unit-testing-private-methods) method because I usually do not test them, I always thought it's more fast to only test public method that will be called from the external of the object.
Do you test private method? or Should I always test private method?
Unit tests I believe are for testing public methods. Your public methods use your private methods, so indirectly they are also getting tested.
If you don't test your private methods, how do you know they won't break?
I do not unit test private methods. A private method is an implementation detail that should be hidden to the users of the class. Testing private methods breaks encapsulation.
If I find that the private method is huge or complex or important enough to require its own tests, I just put it in another class and make it public there (Method Object). Then I can easily test the previously-private-but-now-public method that now lives on it's own class.
I think it's best to just test the public interface of an object. From the point of view of the outside world, only the behavior of the public interface matters and this is what your unit tests should be directed towards.
Once you have some solid unit tests written for an object you do not want to have to go back and change those tests just because the implementation behind the interface changed. In this situation, you've ruined the consistency of your unit testing.
I am not an expert in this field, but unit testing should test behaviour, not implementation. Private methods are strictly part of the implementation, so IMHO should not be tested.
It's obviously language dependent. In the past with c++, I've declared the testing class to be a friend class. Unfortunately, this does require your production code to know about the testing class.
We test private methods by inference, by which I mean we look for total class test coverage of at least 95%, but only have our tests call into public or internal methods. To get the coverage, we need to make multiple calls to the public/internals based on the different scenarios that may occur. This makes our tests more intentful around the purpose of the code they are testing.
Trumpi's answer to the post you linked is the best one.
I tend to follow the advice of Dave Thomas and Andy Hunt in their book Pragmatic Unit Testing:
"In general, you don't want to break any encapsulation for the sake of testing (or as Mom used to say, "don't expose your privates!"). Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there's another class in there struggling to get out."
But sometimes I can't stop myself from testing private methods because it gives me that sense of reassurance that I'm building a completely robust program.
If your private method is not tested by calling your public methods then what is it doing? I'm talking private not protected or friend.
If the private method is well defined (ie, it has a function that is testable and is not meant to change over time) then yes. I test everything that's testable where it makes sense.
For instance, an encryption library might hide the fact that it performs block encryption with a private method that encrypts only 8 bytes at a time. I would write a unit test for that - it's not meant to change, even though it's hidden, and if it does break (due to future performance enhancements, for instance) then I want to know that it's the private function that broke, not just that one of the public functions broke.
It speeds debugging later.
I kind of feel compelled to test private functions as I am following more and more one of our latest QA recommendation in our project:
No more than 10 in cyclomatic complexity per function.
Now the side effect of the enforcing of this policy is that many of my very large public functions get divided in many more focused, better named private function.
The public function still there (of course) but is essentially reduced to called all those private 'sub-functions'
That is actually cool, because the callstack is now much easier to read (instead of a bug within a large function, I have a bug in a sub-sub-function with the name of the previous functions in the callstack to help me to understand 'how I got there')
However, it now seem easier to unit-test directly those private functions, and leave the testing of the large public function to some kind of 'integration' test where a scenario needs to be addressed.
Just my 2 cents.
What is the purpose of testing?
The majority of the answers so far are saying that private methods are implementation details which don't (or at least shouldn't) matter so long as the public interface is well-tested and working. That's absolutely correct if your only purpose for testing is to guarantee that the public interface works.
Personally, my primary use for code tests is to ensure that future code changes don't cause problems and to aid my debugging efforts if they do. I find that testing the private methods just as thoroughly as the public interface (if not more so!) furthers that purpose.
Consider: You have public method A which calls private method B. A and B both make use of method C. C is changed (perhaps by you, perhaps by a vendor), causing A to start failing its tests. Wouldn't it be useful to have tests for B also, even though it's private, so that you know whether the problem is in A's use of C, B's use of C, or both?
Thanks all, most of you look to only test public, like I am. But, haven't you feel that sometime private method would be nice to be tested to know faster that the problem of the public method was a private method? This is why I thought it would be great to test private method sometime.
As quoted above, "If you don't test your private methods, how do you know they won't break?"
This is a major issue. One of the big points of unit tests is to know where, when, and how something broke ASAP. Thus decreasing a significant amount of development & QA effort. If all that is tested is the public, then you don't have honest coverage and delineation of the internals of the class.
I've found one of the best ways to do this is simply add the test reference to the project and put the tests in a class parallel to the private methods. Put in the appropriate build logic so that the tests don't build into the final project.
Then you have all the benefits of having these methods tested and you can find problems in seconds versus minutes or hours.
So in summary, yes, unit test your private methods.
If you are developing test driven (TDD), you will test your private methods.