Как проверить метод void, который изменяет только переменные частного класса?

Question

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

public void init(Properties props) throws Exception { 

    this.language = props.getProperty(Constants.LANGUAGE,Constants.LANGUAGE_DEFAULT); 
    this.country = props.getProperty(Constants.COUNTRY,Constants.COUNTRY_DEFAULT); 

     try { 
      this.credits = Integer.valueOf(props.getProperty(Constants.CREDITS_OPTION_NAME, Constants.CREDITS_DEFAULT_VALUE)); 
     } catch (NumberFormatException e) { 
      throw new Exception("Invalid configuration: 'credits' does not contain a valid integer value.", e); 
     } 
     //rest of method removed for sake of simplicity 
    } 

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

1. Сделать общедоступными методы доступа к закрытым полям, затем вызвать эти методы после тестирования метода init.
2. Сделайте единичный тест только методом вызова init и предположим, что все работало корректно, не было исключено.

Как вы думаете, что является идеальным способом протестировать этот метод?

Answer 1

Вы можете использовать отражение, чтобы получить значения частных полей. Например:

Field field = YourClass.class.getDeclaredField("language"); 
field.setAccessible(true); //override the access restriction of it being private 
field.get(yourObject); 

Если весна на вашем пути к классам, вы можете использовать его ReflectionUtilsReflectionTestUtils /.

Иногда утверждается, что частные поля не должны проверяться, и только публичное состояние объекта является точкой модульного тестирования. С этой точки зрения может быть лучше разоблачить геттер, или даже лучше - выбросить исключение.

Если объект находится в недействительном состоянии, если поля не установлены, то сам объект должен нести ответственность за его действие, путем исключения исключения.

Answer 2

Способствует ли ваш JUnit метод напрямую? Тогда ссылка на объект объекта будет одинаковой, вы должны иметь доступ к языку и стране, поскольку для кредитов выполняется пересчет в вашем JUnit.

Общественный доступ для частных методов также является хорошим выбором.

Answer 3

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

Если вы делаете строгий TDD, вы не должны даже добавить эти поля, пока вы не тест, который на самом деле имеет преимущество них :)

Answer 4

Я хочу утверждать, что язык, страна и поля кредитов были установлены после вызова init

Некоторая философия: почему вас волнует, правильно ли они установлены? Если ответ «так, что класс тогда ведет себя правильно», вы можете проверить, что они были установлены правильно, путем тестирования ожидаемого последующего поведения. Если, однако, их неправильное использование не имеет эффекта, они являются избыточными, и вы должны их удалить.

Другой плакат предложил использовать отражение для доступа к закрытым полям. Я советую против этого; все, что помечено как частное, должно быть детальностью реализации класса и поэтому не должно быть непосредственно протестировано. Вместо этого вы должны проверить опубликованный API своего класса. Тогда у вас есть свобода реорганизовать его легко, изменив детали (частные).

Answer 5

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

BTW: Альтернатива общедоступным геттерам - сделать модульное тестирование в том же пакете и предоставить локальные геттеры.