Is it worth writing a test for a method which has calls to other methods that are 100% covered by individual unit-tests?

Recently I have been reading The Art Of Unit Testing book by Roy Osherove and I was thinking how to deal with such a situation:

Assume that I have a big method that accomplishes a business process based on the passed parameters by completing different tasks:

public void MonsterMehtod(Parameters p)
{
    // Some processes to accomplish TASK_A
    // ....

    // Some processes to accomplish TASK_B
    // ....

    // Some processes to accomplish TASK_C
    // ....
}

And I want to write test(s) on this method.

So, if I exclude this big method to smaller methods like this:

public void MonsterMethod(Parameters p)
{
    Task_A(p);

    Task_B(p); //Can behave different depending on Task_A(p) results

    Task_C(p); //Can behave different depending on Task_A(p) and Task_B(p) results
}

And I write unit tests for each task like this:

[Test]
public void Task_A_AllPossibleConditionsWithParameterP_ExpectedBehaviours() {}

[Test]
public void Task_B_AllPossibleConditions_ExpectedBehaviours() 
{
 // Tests all possible expected behaviours based on injected parameters
 // Tests all possible expected behaviours based on method Task_A(Prameters p) results
}

[Test]
public void Task_C_AllPossibleConditions_ExpectedBehaviours() 
{
 // Tests all possible expected behaviours based on injected parameters 
 // Tests all possible expected behaviours based on method Task_A(Prameters p) results
 // Tests all possible expected behaviours based on method Task_B(Prameters p) results
 // Tests all possible expected behaviours based on method Task_C(Prameters p) results
}

So, after all, is it meaningful to write another test for MonsterMethod(Parameters p) like:

[Test]
public void MonsterMehtod_AllPossibleParameterConditions_ExpectedBehaviours {}

Maybe I can at least write a test to check if all Task_A(), Task_B(),Task_C() methods are called but while I have all the unit tests for each sub-task, is it worth having another test (maybe it should be called an integration test rather than a unit test) for MonsterMethod(Parameters p) that houses all those sub-开发者_Go百科tasks?

If your writing a method, than it presumably does something different than any other method you already have. It is useful then to test that it does that other thing (be it correctly composing the results of other functions) correctly.

You should test the monster method with how you expect it to handle the child tasks. That does not mean, however, that you need to execute the child tasks.

I would suggest stubbing out the child methods, and testing the monster method in isolation.

This can easily be done by making each Task method virtual and using a mocking framework to stub out the child methods, or just manually doing it yourself.

I would say it's worth it. If you end up removing some the inner tasks then your Monster method will still be tested.