I agree that unit tests for internal (non public) functionality are not particularly useful, and can hamper your willingness to change an internal implementatio

I agree that unit tests for internal (non public) functionality are not particularly useful, and can hamper your willingness to change an internal implementation for the better. I also agree it's painful to trace through dozens of classes/methods to determine what the actual implementation is. However, I don't agree the culprit is small methods. Small, interdependent methods in a single class (or package) are great and can be easy to follow if they are consistent. Usually the culprit is overuse of inheritance and design patterns. However, one case where I find myself being less "fancy" is functions that run/generate SQL statements. Although there are many cases where you can re-use certain portions of SQL statements and build up a query through smaller functions, this ends up being a nightmare to debug. I find it is better to be as plain and explicit as possible.