2013-12-19 3 views
0

Я раскалываю несколько расходящихся мнений о тестировании частного метода. Мне было интересно на сегодня, что такое соглашение defacto с тестированием частного метода. Можно ли проверить их?Когда это нормально, чтобы проверить частный метод?

Если нет, то почему так много инструментов для тестирования позволяют их протестировать? Я использую scalatest, и есть что-то для этого. Я полагаю, это должно быть потому, что в определенной ситуации это очень полезно. С другой стороны, я красный, рекомендации, такие как, тест поведение не метод.

Следовательно, с этой путаницей мне было интересно, сможет ли кто-нибудь поделиться своим опытом и мудростью по этому вопросу. Когда было бы целесообразно проверить их и когда их избежать? Каковы общие рекомендации.

Большое спасибо

ответ

0

«Тестирование не метод» - хороший подход. Что означает единичный тест, так это то, что вы тестируете свой класс с точки зрения пользователя. И все ваши частные методы должны в конечном итоге быть вызваны из ваших общедоступных методов. Иначе почему они когда-либо были в вашем классе в первую очередь?

Вкратце - вы должны всегда проверять свои частные методы косвенно из ваших общедоступных методов.

+0

Спасибо за ваш ответ Денис. Однако как бы вы оправдали существование специальной поддержки в большинстве рамок для тестирования частного метода? В чем смысл? – MaatDeamon

+0

Также я должен признать, что я почувствовал себя странным при написании частного метода и вынужденным образом нарушить этот цикл TDD. Это означает, что для частного метода я все равно буду тестировать вещи вручную, чтобы убедиться, что он создает то, что я хочу, при применении реального TDD для моего общедоступного метода. Например. Я бы применил данные, когда при тестировании моего общественного поведения, и ручное тестирование для моих личных методов. Я просто нахожу это странным. Один из них настолько полезен для разрушения кода и мыслей с использованием техники TDD, но должен вернуться к старой привычке для частных методов. – MaatDeamon

+0

Правильно ли? Для меня, чтобы не нарушить цикл TDD, лучший способ - сломать мой тест. Более конкретно, если мои методы действительно представляют внутренние шаги моего поведения, тогда мой тест должен проверить результат всех этих шагов. Например, с «Given When Then» + «And» и «Ключевое слово» допускает соединение «проверки результата» или «условия». Следовательно, можно поэтому постепенно продвигаться к тестированию всего поведения, проверяя результат разных шагов с помощью «И». Поэтому в некотором смысле у вас будет «Then» тестирование первого частного метода, а «А» - второе и так далее .... – MaatDeamon

Смежные вопросы