[wmayner]

What if a public function is very complicated—too complicated to be considered a unit—and it calls several simpler private functions? Those helpers should be tested with their own unit tests, but shouldn't be exported.

It's not just about coverage in terms of code execution; you also want the right test “resolution”, so you can quickly find the level of abstraction where a bug is, and so you can prove correctness of the parts of a complicated function as you build it.

[CrossEye]

The other side of this, though, is that you're now coupling your tests to the implementation of your solution and not the interface you want to present. You can't simply refactor your code to improve it; you will also have to find the failing tests, remove them, and write new ones for your new private functions, all while the public behavior of your system has remained working perfectly.

That's my primary reason for not testing private functions.

My alternative is simple, and has been stated elsewhere in the thread; if a function rises to the level of complexity of really needing its own tests, then it probably should be exposed as a public function somewhere in my system. Otherwise, I haven't factored the problem properly yet.

[wilmoore]

Exactly...coupling is more detrimental than one would think. As your codebase gets larger and more developers on-board and features change, what should have been a simple refactor can turn into a nightmare as your test suite starts to give false negatives because you've changed the implementation or removed a now unused private function that your tests relied upon directly. Writing unit tests directly against private functions is a good way to ensure your team's velocity doesn't scale as well as it should.

Unit tests will serve you better when written to assert results rather than implementation details.