Здравствуйте, another_coder, Вы писали:

_>Все логично. Либо он является частью внутренней логики и неявно тестируется через публичные классы. Либо он является отдельным модулем и должен тестирвоаться отдельно. Случай, когда тестируется приватный метод, это признак нескольких проблем:

С этим можно было бы согласиться, если бы не одно "но". Тестирование через публичные методы включает в себя тестирование этого приватного метода плюс того, что есть в публичном методе. А публичные методы делаются не из соображений тестирования, а опять-таки из соображений логики класса.
В результате получаются 2 альтернативы, и обе хуже
1. Сделать публичные методы специально для тестрования. Тут, я думаю, комментарии излишни.
2. Тестировать те публичные методы, которые действительно должны быть в классе. Но они содержат вызов приватного и что-то свое (если своего нет, то сделать этот приватный метод публичным, а публичный выкинуть, и все дела). Значит, мы тестируем и приватный метод, и что-то еще. А это что-то еще, возможно, накладывает ограничения на вызов приватного метода. Например, не допускает его вызов с нулевым аргументом. В этом случае мы так никогда и не узнаем, корректно ли отработает этот приватный метод, если ему передать null. Да, можно возразить — раз его вызывают только из публичного, блокирующего передачу null, значит это не так уж важно. Возражение, однако , снимается простым соображением. А если этот приватный метод будет потом вызван еще одним публичным методом, который эту блокировку передачи null не производит ? Обнаружится ошибка довольно быстро, так как для нового публичного метода, будем полагать, тут же будет написан "исчерпывающий" набор тестов. Но когда это будет ? Вполне возможно, что через пару лет, и совсем другим разработчиком в процессе поддержки. И выскажется этот разработчик в адрес первого разработчика весьма нелестно.

Вот так как-то.

Здравствуйте, another_coder, Вы писали:

_>Все логично. Либо он является частью внутренней логики и неявно тестируется через публичные классы. Либо он является отдельным модулем и должен тестирвоаться отдельно. Случай, когда тестируется приватный метод, это признак нескольких проблем:

С этим можно было бы согласиться, если бы не одно "но". Тестирование через публичные методы включает в себя тестирование этого приватного метода плюс того, что есть в публичном методе. А публичные методы делаются не из соображений тестирования, а опять-таки из соображений логики класса.
В результате получаются 2 альтернативы, и обе хуже
1. Сделать публичные методы специально для тестирования. Тут, я думаю, комментарии излишни.
2. Тестировать те публичные методы, которые действительно должны быть в классе. Но они содержат вызов приватного и что-то свое (если своего нет, то сделать этот приватный метод публичным, а публичный выкинуть, и все дела). Значит, мы тестируем и приватный метод, и что-то еще. А это что-то еще, возможно, накладывает ограничения на вызов приватного метода. Например, не допускает его вызов с нулевым аргументом. В этом случае мы так никогда и не узнаем, корректно ли отработает этот приватный метод, если ему передать null. Да, можно возразить — раз его вызывают только из публичного, блокирующего передачу null, значит это не так уж важно. Возражение, однако , снимается простым соображением. А если этот приватный метод будет потом вызван еще одним публичным методом, который эту блокировку передачи null не производит ? Обнаружится ошибка довольно быстро, так как для нового публичного метода, будем полагать, тут же будет написан "исчерпывающий" набор тестов. Но когда это будет ? Вполне возможно, что через пару лет, и совсем другим разработчиком в процессе поддержки. И выскажется этот разработчик в адрес первого разработчика весьма нелестно.

Вот так как-то.