Стоит ли писать тест для метода, который вызывает другие методы, которые на 100% покрыты отдельными юнит-тестами?

Question

Недавно я читал книгу Роя Ошерова «Искусство единичного тестирования» и думал, как справиться с такой ситуацией:

Предположим, у меня есть большой метод, который выполняет бизнес-процесс, основанный напередал параметры, выполнив различные задачи:

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

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

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

И я хочу написать тест (ы) для этого метода.

Итак, если я исключу этот большой метод для меньших методов, таких как этот:

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
}

И я пишу модульные тесты для каждой задачи следующим образом:

[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
}

Так что, в конце концов, имеет смысл написать еще один тест для MonsterMethod (Параметры p), например:

[Test]
public void MonsterMehtod_AllPossibleParameterConditions_ExpectedBehaviours {}

Возможно, я могу хотя бы написать тест, чтобы проверить, все ли методы Task_A (), Task_B (), Task_C () называются , но пока у меня есть все модульные тесты для каждой подзадачи,стоит ли проводить еще один тест (возможно, его следует называть интеграционным тестом, а не модульным тестом) для MonsterMethod (параметры p), в котором находятся все эти подзадачи?

Answer 1

Если вы пишете метод, то он, вероятно, делает что-то отличное от любого другого метода, который у вас уже есть. Тогда полезно проверить, правильно ли он выполняет эту функцию (будь то правильно составляя результаты других функций).

Answer 2

Вы должны протестировать метод monster с тем, как вы ожидаете, что он будет обрабатывать дочерние задачи.Это не означает, однако, что вам нужно выполнять дочерние задачи.

Я бы предложил заглушить дочерние методы и протестировать метод монстров изолированно.сделав каждый метод Task виртуальным и используя макетную среду для исключения дочерних методов, или просто вручную сделав это самостоятельно.

Answer 3

Я бы сказал, оно того стоит.Если в итоге вы удалите некоторые внутренние задачи, ваш метод Monster все равно будет протестирован.