you shouldn't be testing internal implementation anyway
Why not? When my big black box stops giving me the expected answers I want to know exactly which cog inside that box that broke.
Why not? When my big black box stops giving me the expected answers I want to know exactly which cog inside that box that broke.
I agree that there's nothing worse than a test that says "your stuff broke" and provides no additional information why. But there's a balance between that, and testing the internals of an implementation.
What kind of test could you possibly write that would break because of this? Something that measures time or memory usage, or uses reflection?
If you have clearly defined interfaces between significant internal components (which you should), why not test that they do what you ask? Public vs. internal is often more about what is exactly the client of the code, not the code's function or structure itself.