A module’s public interface is its contract with the world. Its privates are nobody’s business. (That’s why they’re called “private”.)
When you write unit tests for a module, test only the public interface. (In fact, the tests should read like documentation for the module’s public interface.)
If you find yourself caring about the module’s privates when writing tests, you’re probably going down a path you’ll regret. Stop and think about your design.
If you find yourself making things public just for the tests, that’s another bad sign. Stop and think.
The code calling a module is its client. When the client calls something on the public interface, what’s the expected result from the client’s perspective? Questions like that should shape your module’s public interface, and furthermore should shape how you separate your code into modules to begin with.
