Модульное тестирование открытого метода, который вызывает несколько частных методов

Question

Я хочу проверить открытый метод, который вызывает несколько частных методов. То, что я прочитал из всех ответов на ранее заданные вопросы, различно. Некоторые говорят, что если кто-то сталкивается с такой ситуацией, то, вероятно, структура неправильна, или методы, которые вызывают другие методы без какой-либо логики, не должны проверяться и т. Д.

Что мне неясно, так это то, что я должен издеваться над этими закрытыми методами (используя PowerMock или любую основанную на отражении библиотеку) и модульное тестирование только этим методом, или я должен предоставлять различные типы входных данных, чтобы все случаи были проверено, но частные методы также будут вызваны. В последнем случае, это все еще будет модульное тестирование, так как я буду вызывать и другие методы.

class ClassToTest {

    public void publicMethod (Argument argument) {
        try {
            privateMethod1();

            privateMethod2(argument);

            privateMethod3();
        } catch (Exception ex) {
            privateMethod4();
        }
    }

}

Answer 1

Во-первых, важно понимать, что попытки сохранить комплекты юнит-тестов полностью независимыми от деталей реализации могут привести к неэффективным комплектам тестов, т. Е. Комплектам тестов, которые не подходят для поиска всех найденных ошибок. И поиск ошибок - это одна основная цель тестирования (см. Майерс, Бадгетт, Сандлер: искусство тестирования программного обеспечения или «Бейзер: методы тестирования программного обеспечения» и многие другие).

Альтернативные реализации одного и того же интерфейса имеют разные потенциальные ошибки. Тесты для итеративной / рекурсивной реализации функции Фибоначчи будут выглядеть иначе, чем для реализации, использующей выражение закрытой формы из Moivre / Binet, или для реализации из таблицы поиска.

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

Во-вторых, очень вероятно, что вы не должны насмехаться над закрытыми методами, а просто использовать их как часть своих тестов. Я говорю очень вероятно, потому что это зависит от методов. Насмешка должна быть сделана по причине (и избежать иначе). Веские причины:

• Вы не можете легко заставить зависимый компонент (DOC) вести себя так, как предназначено для ваших тестов.
• Вызывает ли вызов DOC какое-либо недерминистское поведение (дата / время, случайность, сетевые подключения)?
• Тестовая настройка слишком сложна и / или требует интенсивного обслуживания (например, необходимость во внешних файлах)
• Исходный DOC создает проблемы переносимости для вашего тестового кода.
• Вызывает ли использование оригинального DOC неприемлемо длительное время сборки / выполнения?
• Имеют ли проблемы со стабильностью (зрелостью) DOC, которые делают тесты ненадежными, или, что еще хуже, DOC еще не доступен?

Например, вы (обычно) не высмеиваете стандартные библиотечные математические функции, такие как sin или cos, потому что у них нет ни одной из вышеупомянутых проблем. Вам нужно будет оценить, применимо ли это к вашим личным методам.