Hacker News Reader

Comment by rustyminnow | Hacker News Reader

I've used this pattern before, but run into issues when you want to write tests for "private" functions (like loadSong() in this example). What I've done is name them like _loadSong and expose them anyways, but that doesn't feel great.

Is there a better way?

View on HN

You don't write tests for private methods.

Why not?

The most obvious reason is that they're private and not normally reachable from your test code.

But even conceptually there are problems with testing private methods. For example they likely expect to be called only while the class is in some specific state or in the middle of some atomic operation. Otherwise they could have just been made public.

Because it’s assumed those private methods’ usage happens within public methods, which should be tested. By testing the public methods and all of its use cases you are also testing private ones. That way you can arbitrarily modify private methods without touching the tests (presuming you’re refactoring and don’t need to modify behavior).

This seems to be building on rocky foundations though. It's unlikely a functions entire test vector gets checked during testing. This is a known risk (you can't test everything) but by leaving all the functions under a public function untested there is no safety net.

If the code of the private methods cannot be fully exercised through the class' public interface, then that code never executes and should not even be in the function.

Of course private methods should be tested. These are unit tests, not functional/integration tests.

You don't unit test private methods, the "unit" is the exposed surface of the class.

Reply on news.ycombinator.com