Как проверить приватные методы на Java?

Возможный дубликат: Что наилучшим способом частного тестирования отдельных методов?

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

Проблема заключается в методах private - они не могут тестироваться вне их классов.

Должен ли я решить эту проблему, изменив все методы, от private до protected, и пусть тестовый класс расширяет класс источника? Или есть лучшее решение?

Мое решение (private splitLetters = > protected splitLetters) будет работать следующим образом:

Класс источника:

class MyClass{
  protected splitLetters(int num){
    return num+2;
  }
}

Класс тестирования:

class Test_MyClass extend MyClass{
  public splitLettersTest(){
  for(int i=0;i<100;i++){
    System.println(parent.splitLetters(i));
  }
 }
}

Решения:

Не тестировать частные методы. Иногда частный метод выполняет очень сложные задачи, которые должны быть проверены очень хорошо, и мы не хотим, чтобы у этого пользователя был доступ к этим методам. Вскоре решение изменяет частные методы на защищенные.
Вложенный способ класса для тестирования - проблематично, поскольку QA вносит изменения в исходный код
Отражение. Если это позволяет вызвать частные методы, это выглядит как отличное решение http://www.artima.com/suiterunner/private3.html (Я должен узнать больше, чтобы понять рефлексию. Я не понимаю, как отражения не нарушают идею создания публичных и частных методов, если мы можем вызвать частные методы из другого класса.)
Не определять частные методы (как я показал в своем решении) - проблематично, потому что иногда нам приходится определять частный метод.

Ответ 1

Посмотрите на эту статью о тестировании частных методов с помощью JUnit.

Ответ 2

Вам не нужно проверять личные методы.

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

Ответ 3

Мое личное мнение заключается в том, что вы должны (где это возможно) тестировать поведение, которое подвергается конечному пользователю этой части функциональности, и поэтому вам не следует проверять частные методы:

Тест не доказывает ничего, кроме как показать, что часть внутренней функциональности "работает" согласно чему-то, что не имеет смысла для людей, фактически использующих ваше программное обеспечение.
Если вы измените/перефакторируете свою внутреннюю реализацию, вы можете обнаружить, что ваши тесты устройств начинают сбой, когда фактически внешняя функциональность не изменилась вообще!

Конечно, вы можете подразделить большие проекты на более мелкие куски функциональности, и в этом случае вы можете выбрать unit test интерфейсы между интерфейсами (например, вы можете выбрать unit test ваш уровень доступа к данным, несмотря на тот факт, что реализация DAL напрямую не влияет на конечного пользователя).

Ответ 4

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

Ответ 5

Тестирование частных методов подразумевает тестирование, а не функциональность. Подумайте очень тщательно о том, почему вы хотите проверить частные методы, и вы можете обнаружить, что вам не нужно их вообще тестировать.

Ответ 6

На мой взгляд, частные методы не должны проверяться. Тесты для интерфейсов (в широком смысле этого слова).