Dealing with private methods (whitebox test), methods with many conditions

Question

I have 2 questions:

1) In JUnit you shouldn't test or mock private methods. But how do I deal with, when they are getting called inside a public method. Let's assume I have following setup:

public void method(String value){
    if(value.contains("something")){
        doSomethingToString(value);
    }
    else{
        //do something else
    }
}

private void doSomethingToString(String value){
    Object obj = service.getObject();   //service is mocked in my test-class
    //do something with the obj and value
}

I am doing a whitebox test, so I know the methods and what's going on. Now I want to test the public method method(String value). When I now only consider what happens in there, I would get into trouble, since I need to influence what service.getObject() in my private method returns. Is it OK, when I just go on, like I would, meaning using doReturn(objectICreatedInMyTestClass).when(service.getObject()) or do I need to find another way?

2) Methods which have more than one conditions. For example:

public void method(String value){
    if(value.contains("something")){
        Object obj = service.getObj(value);
    }
    else{
        //do something else
    }

    if(obj.getAddress == null){
        //do something
    }
    else{
        //do something else
        }

    if (obj.getName == "Name") {
        // do something
    } 
    else 
    {
        // do something else
    }
}

How many times do I need to test this method? Only twice, where once all conditions return true, and second, where they all return false? Or is it advised to test every possible scenario? This would mean test with condition 1 = true, condition 2 = false, condition 3=false, and then condition 1 = true, condition 2 = true, condition 3 = false and so on (= 8 possibilites).

Answer 1

1) Should I test private methods on their own, outside of the public methods that call them?

Typically I've always followed the assumption that if the only way your code will access that method is by going through another, then that's how you should test it. My experience with testing systems has lead me to believe that this is generally the way it's done in 'the real world' as well.

If we take your example, we can assume that our first step is to write tests to thoroughly test our main method. As part of this we should be testing scenarios that include properly exercising all the conditions we could expect it to face. This will include at least a subset of the scenarios that your private method will face.

Your private method may be used by multiple (possibly wildly different) methods, so its space of possible inputs and outputs may be greater than any single public method that uses it. If you thoroughly test the public methods that use them however, you should be in the situation where you are testing all of the possible scenarios that that private method will encounter.

Because of this you shouldn't need to write tests specifically for the private method. There may be other scenarios where it is unavoidable to try and test private methods, or private classes. Usually I would argue this is because the code is simply written in a way that makes it hard/impossible and could be rewritten to make it friendlier to tests (And therefore friendlier to being updated/refactored at a later date).

2) Should all of those combinations be tested?

This depends on what is happening in the example. There are two different scenarios to consider

a) Neither of these branches have anything to do with each other. That is, what ever happens in the first set of branches will have no way of impacting the logic of what happens in the second branch.

b) Some possible implications of running any logic in either of the first set of branches would result in a different result in the logic of the code in one or more of the second branches.

This will be down to your reading and understanding what is happening in the code, so your example isn't enough to point to one or the other way of doing things.