I notice that when I code I often use a pattern that calls a class method and that method will call a number of private functions in the same class to do the work. The private functions do one thing only. The code looks like this:public void callThisMethod(MyObject myObject) {    methodA(myObject);    methodB(myObject);  // was mehtodB before}private void methodA(MyObject myObject) {    //do something} private void methodB(MyObject myObject) {    //do something}Sometimes there are 5 or more private methods, in the past I have moved some of the private methods into another class, but there are occasions when doing so would be creating needless complexity. The main reason I don't like this pattern is that is not very testable, I would like to be able to test all of the methods individually, sometimes I will make all of the methods public so can I can write tests for them. Is there a better design I can use?
Is this pattern bad?
java;design patterns;unit testing;code quality
It's a good pattern. This is what Uncle Bob refers to when he talks about extracting til you drop.It shouldn't affect your tests though. You should only be testing the public interface. Yes, you can reflect your way in and test the private methods, but you're still going to have to test them again when you test your public methods, so it doesn't solve the perceived problem.The problem comes when you're testing a private method multiple times because you have multiple public methods using them.Sometimes, in fact more frequently than you might think, this doesn't matter. Particularly if you're testing by behaviour, rather than trying to test each line of code. All you want to know is Does this public method do what it's supposed to do? You don't care about the implementation details.It does matter, however, when you're testing the same piece of complex logic repeatedly, because it adds multiple tests to each behaviour. At that point, simply extract it into a service and mock it out.