Как протестировать побочные эффекты метода в c ++?

Question

В реальном проекте C ++ большинство методов имеют побочные эффекты, помимо возврата значения и изменения выходного параметра.

// For examle
bool A::doA()
{
    bool isSuccess = true;
    isSuccess &= b.doB();
    isSuccess &= c.doC();
    this->a++;
    return isSuccess;
}

Побочные эффекты вышеупомянутого метода включают вызов 2 методов и изменение переменной-члена a.
Однако, когда пишу unittest для вышеуказанного метода, я вижу, что большинство людей просто проверяют возвращаемое значение и игнорируют побочные эффекты, которые достигают 100% покрытия кода.
Но я думаю, что такой unittest глуп по двум причинам:
1. Основная функция метода doA - это побочные эффекты, а не возвращаемое значение.
2. Если doA имеет возвращаемое значение void (что часто встречается в реальном коде), вы даже не можете написать unittest таким образом.

В Google я нашел способ протестировать побочные эффекты:
1.mock b и c и проверить, вызваны ли doB и do C.
2.check value переменной члена через некоторую технику.
Но я думаю, что такой юнит-тест не годится по двум причинам:
1. Будет так много насмешек и времени. Кроме того, кажется глупым просто проверять, вызывается ли метод.
2. Это зависит от реализации метода, а не интерфейса, если реализация изменится, нужно изменить unittest. И я слышал, кто-то говорит, что unittest должен быть тестом черного ящика.

Так как вы решаете такую ​​проблему в реальном проекте?

Answer 1

В общем:

Тесты всегда проверяют какое-либо публично наблюдаемое поведение. Не имеет значения, является ли это поведение возвращаемым значением или побочным эффектом. API и / или документация тестируемого кода Cour должны прояснить, каковы именно побочные эффекты. Если побочные эффекты не демонстрируют общедоступного поведения, они являются только внутренней деталью реализации и не имеют отношения к тесту; также они не должны быть частью API publi c или его документации.

Как правило, не проверяйте вещи, о которых вы только знаете, потому что вы смотрели на реализацию тестируемый код.

Что касается вашего примера:

Если doB() или doC() вызывают соответствующие побочные эффекты, это часть наблюдаемого поведения doA(). Проверьте сами эффекты. Независимо от того, были ли они вызваны непосредственно doA() или другой функцией, вызванной внутри doA(), это деталь реализации и, следовательно, не имеет значения для вашего теста.

Возможно, эффект «выполнения А» добавляет это конкретное A объект в реестре. Тогда правильнее всего проверить, зарегистрирован ли объект.