Should I test private methods or only public ones? [closed]

Answer 1

If you are developing test driven (TDD), you will test your private methods.

Answer 2

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.

-Adam

Answer 3

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.

Answer 4

Unit tests I believe are for testing public methods. Your public methods use your private methods, so indirectly they are also getting tested.

Answer 5

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.

Answer 6

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.