I've never seen any recommandation that you shouldn't define unit tests for your own private functions. As soon as you have something which might fail, a unit test may be useful. I even think my most useful unit tests are for very technical private functions at the core of my libs.
It's possible the recommandation you've read was more about exposing it just for the tests, or maybe related to functions whose signature or existence was unstable, or maybe a java specific problem ? Care to share the source of the advice you got ?
Actually, I first got this recommendation from StackOverflow. Then I did some digging, and this article is at the top of google for the key phrase “should I test private methods.”
To your point about it being a Java problem, it sort of is. You can’t test private methods—at least not directly—which makes it painful to actually go about writing any tests.
Also, for the record, I totally agree with you. I find it odd, however, that there seems to be some “accepted truth” at least on the internet about it.
But I might have a different approach to tests: It is my opinion that, just like it's useless to add a "return the thing" comment in front of every getter, it's useless to add mundane tests which can't fail. A test is a piece of code, which you must understand, maintain, and which must have a reason. A test is needed when you may imagine the tested function might fail (even if you can't imagine how).
The main reason to test a function isn't because it's public, but because it might fail.
Most public API reduce the possibilities of the underlying core, for various reasons. But as the implementer of this core, you still may want to ensure the core does what it's supposed to do.
And a public API offers most often many ways to call the same underlying implementation. Refusing to test the implementation would involve duplicating the tests for all facades, which means you bloat your tests.
There is some amount of white box testing that I think is important. How do you know a public API works if you don’t test the limits of the internals? Do you just blindly throw inputs at it and hope for the best?
I disagree here. Your private methods are implementation details. You should only need to test the public interface to the API. If you are finding your public methods are dependent on too many various private methods it is a sign that they themselves can be broken into a class.
Yes but tests are also meant to check the implementation works as intended.
If you are finding your public methods are dependent on too many various private methods it is a sign that they themselves can be broken into a class.
It's more often the opposite: a core private function, accessed through several public functions, none of them covering the whole possibilities of the function doing the real job (and the one also which may fail). In such a case, testing all the public functions adds a lot of noise and reduces the stress put on the function which matters.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've never seen any recommandation that you shouldn't define unit tests for your own private functions. As soon as you have something which might fail, a unit test may be useful. I even think my most useful unit tests are for very technical private functions at the core of my libs.
It's possible the recommandation you've read was more about exposing it just for the tests, or maybe related to functions whose signature or existence was unstable, or maybe a java specific problem ? Care to share the source of the advice you got ?
Actually, I first got this recommendation from StackOverflow. Then I did some digging, and this article is at the top of google for the key phrase “should I test private methods.”
To your point about it being a Java problem, it sort of is. You can’t test private methods—at least not directly—which makes it painful to actually go about writing any tests.
Also, for the record, I totally agree with you. I find it odd, however, that there seems to be some “accepted truth” at least on the internet about it.
I get what they mean but I disagree.
But I might have a different approach to tests: It is my opinion that, just like it's useless to add a "return the thing" comment in front of every getter, it's useless to add mundane tests which can't fail. A test is a piece of code, which you must understand, maintain, and which must have a reason. A test is needed when you may imagine the tested function might fail (even if you can't imagine how).
The main reason to test a function isn't because it's public, but because it might fail.
Most public API reduce the possibilities of the underlying core, for various reasons. But as the implementer of this core, you still may want to ensure the core does what it's supposed to do.
And a public API offers most often many ways to call the same underlying implementation. Refusing to test the implementation would involve duplicating the tests for all facades, which means you bloat your tests.
Now this is an argument I can get behind.
There is some amount of white box testing that I think is important. How do you know a public API works if you don’t test the limits of the internals? Do you just blindly throw inputs at it and hope for the best?
I disagree here. Your private methods are implementation details. You should only need to test the public interface to the API. If you are finding your public methods are dependent on too many various private methods it is a sign that they themselves can be broken into a class.
Yes but tests are also meant to check the implementation works as intended.
It's more often the opposite: a core private function, accessed through several public functions, none of them covering the whole possibilities of the function doing the real job (and the one also which may fail). In such a case, testing all the public functions adds a lot of noise and reduces the stress put on the function which matters.