Unit Test: Should I write test for branch or called methods?

Question

When I write Unit Test, sometimes I faced situations as shown below. There is a method createOrUpdate that calls another methods based on a condition. In this scene, I have 2 options:

1. I can write a test for all of 3 methods and in the first test method ( createOrUpdate ), just verify if the other methods ( create or update ) is called. In the other test methods, I write test as usually written.

2. I can write multiple tests just for the first method ( createOrUpdate ) and test the other 2 methods based on the condition. Then I think I could test all of these 3 methods.

As I am new in Unit Testing, I just wanted to be clarified which approach is a proper or suitable approach for Unit Testing. Any help would be appreciated.

countryService:

public CountryDTO createOrUpdate(UUID uuid) {
    if (countryRepository.existsByUuid())
        return update(uuid);
    else
        return create(uuid);
}


public CountryDTO create(UUID uuid) {
    // ...    
}


public CountryDTO update(UUID uuid) {
    // ...
}

Answer 1

This actually depends on your implementation of functions.

In case #create and #update functions are only getting called from #createOrUpdate function, then second appraoch (just writting the tests for #createOrUpdate function) makes much more sense.

In case #create and #update functions can be accessed by external classes/functions as well, then the first approach (writting tests for individual) makes more sense. Since you can send different types of data to the function directly, allowing you to cover all the ground properly. Eg: You can test out what will happen when UUID is not present and someone is calling your #update function.

Overall, you can use both of these approach till your are covering all the cases properly.

Answer 2

Apologies for long answer:

---

First you need to understand why we write Junit test cases.

The main reason is to make sure our public methods behaves as expected for all possible input combinations for the users of that method, so each public method need to have their own test cases to assert the behavior of that method, Test case of one method should not know if any other method which is using it is also having test cases

---

Lets understand Why and How:

---

Assume if you go with your 1st approach -

I can write a test for all of 3 methods and in the first test method (createOrUpdate), just verify if the other methods (create or update) is called. In the other test methods, I write test as usually written.

Let's think from the point of view of the users of method createOrUpdate

what if tomorrow someone makes any changes in method 2, and method 3, they will just update the test case for those 2 methods and you the test case of method 1 won't identify the change in behavior of method 1 which is a bug for users of method 1

So to avoid such future bugs you need to write test case to assert the behavior of the methods, not just if the method is calling some others method or not

Now assume if you go with your 2nd approach -

I can write multiple tests just for the first method (createOrUpdate) and test the other 2 methods based on the condition. Then I think I could test all of these 3 methods.

Let's think from the point of view of the users of method create and update -

what if in your current code of first method (createOrUpdate) you need some extra behavior, and you go ahead and update the internal called methods(2, 3) instead of writing new code in method 1?? ..You will fulfill the future needs of method 1, and update test cases of method 1 only, but as there are no separate test cases for method 2, method 3 you won't know if you have broken needs of method 2, method 3 users!!

Which can create bug for users of method 2, and method 3!!

So to avoid such future bugs you need to write test case to assert the behavior of each method separately, if if you find some test logic redundant in multiple test cases