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

Недавно я читал книгу Роя Ошерова The Art Of Unit Testing и думал, как поступить в такой ситуации:

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

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(Parameters p), например:

[Test]
public void MonsterMehtod_AllPossibleParameterConditions_ExpectedBehaviours {}

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


unit-testing integration-testing .net c#
person pencilCake    schedule 08.11.2010    source источник

Ответы (3)


arrow_upward
3
arrow_downward

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

Я бы предложил заглушить дочерние методы и протестировать метод монстра изолированно.

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

person Joseph    schedule 08.11.2010
comment
Джозеф, например: я создам заглушку для Tes_A(), чтобы создать возможные условия для тестирования метода Test_B() в методе Monster. Но, может быть, я бы выбрал интерфейсы, а не виртуальный метод. В любом случае, спасибо! - person pencilCake; 08.11.2010

arrow_upward
4
arrow_downward

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

person Zack Bloom    schedule 08.11.2010

arrow_upward
1
arrow_downward

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

person Lareau    schedule 08.11.2010
comment
Но значит ли это, что я должен дублировать некоторые тесты для большего? У тебя есть какая-то стратегия? - person pencilCake; 08.11.2010