To what extent do you unit test internal/private components of a class/module/package/etc? Do you test them at all or do you just test the interface to the outside world? An example of these internal is private methods.
As an example, imagine a recursive descent parser, which has several internal procedures (functions/methods) called from one central procedure. The only interface to the outside world is the central procedure, which takes a string and returns the parsed information. The other procedures parse different parts of the string, and they are called either from the central procedure or other procedures.
Naturally, you should test the external interface by calling it with sample strings and comparing it with hand-parsed output. But what about the other procedures? Would you test them individually to check that they parse their substrings correctly?
I can think of a few arguments:
- More testing is always better, and this can help increase code coverage
- Some internal components might be hard to give specific inputs (edge cases for example) by giving input to the external interface
- Clearer testing. If an internal component has a (fixed) bug, a test case for that component makes it clear that the bug was in that specific component
- Refactoring becomes too painful and time-consuming. To change anything, you need to rewrite the unit tests, even if the users of the external interface are not affected
- Some languages and testing frameworks don't allow it
What are your opinions?