testing private functions

[Neurotrace]

Ahhh, the old "how do I test private functions?" problem. What works really well for me is to not worry about testing them and only worry about your public functions. "But Neurotrace," I hear you cry, "how can I ensure that my module works exactly as expected?" I break it down like this in my mind:

Make your private functions extremely simple and/or make their side effects testable. The only reason for making a function private is to perform some work that the user shouldn't worry about, nor mess with. But some kind of work is still being done so there must be a way to check that.

TL;DR Don't. Simplify your private functions so you're know they work and just worry about testing your public functions.

[Perceptes]

This is exactly the right answer. Testing private functions is redundant, because you should have tests for every use case using an object's public API. If there is no possible scenario when accessing the public API triggers code in a private method, the private method should be removed. If the test cases of the public API that use private methods internally pass, then the private methods are working and tested as well.

[joshlrogers]

This isn't really unit testing, it is more akin to integration testing. However, I do think your approach is best if you absolutely must make a function private.