2015-06-11 5 views
1

Меня попросили написать тестовый пример junit для Listener.class. Пулы слушателей для каталога и , если есть запрос, который обрабатывается.Проблемы с написанием заметок с ошибкой

Вопросы, которые я облицовкой

  • много методов внутри Listener.class являются частными или защищенными.
  • Слушатель - это поток, и он не запускается именно так. Перед началом инициализации слушателя и многими другими задачами.

Прогресс до сих пор:

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

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

Так как я могу проверить код?

Мой поток программы - это что-то вроде этого.

  1. ServerConfiguration.class -> где конфигурация системы проверяется, яв-Verion и т.д.
  2. читает Server.xml
  3. ServerService.class -> Делает список всех слушателей, адаптеров и магазинов в хэш-карте, конфигурирует порты для прослушивателя и адаптеров
  4. Serverservice.class-> Теперь запускаются только те слушатели, которые отмечены как активные в XML-файле.

В моем случае Слушатели - это управляемый интерфейс. и они создаются потоком,

Просьба дать мне свои данные.

UPDATE

Теперь мой вопрос, как я могу запустить тестовый пример для метода, когда он использует переменные супер class.When я запускаю тест, он всегда будет терпеть неудачу, поскольку эти значения не инициализирован. Как мне продолжить?

private boolean params() 
     { 
     String integrity = ""; 
     String sWAnswer = ""; 
     try 
     { 
      try 
      { 
      integrity = super.getParam("CHECK_INTEGRITY"); 
      sWAnswer = super.getParam("WRITE_ANSWER"); 


      **Some Business Logic** 

      super.info("Request Directory : " + sRequestPath); 
      super.info("Response Directory : " + sResponsePath); 
      super.info("Error Directory : " + sErrorPath); 
      } 
     } 
     catch (Exception ex) 
     { 
      bCheck = false; 
     } 
     return bCheck; 
     } 
+2

Похоже, что код, который вы тестируете, должен быть реорганизован для обеспечения модульного тестирования. Тем не менее, прежде чем делать это, хорошо убедиться, что есть достаточный интеграционный тест вокруг кода, который вы реорганизуете, чтобы вы знали, что ваш рефакторинг что-то сломает. Прочитайте * Эффективно работайте с устаревшим кодом * Michael Feathers для получения более подробной информации о том, как проверить код, подобный этому – NamshubWriter

ответ

2

Это было время, так как я использовал EasyMock, но вы можете захотеть взглянуть на Partial Mocking Также я предполагаю, что на «.class» вы имеете в виду «.java».

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

Как правило, вы минимизируете использование mocks или не используете их вообще для теста интеграции, потому что вы проверяете, что все ваши части правильно совпадают.

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

[отредактирован для правильности] Если метод, который необходимо проверить, - private, имеет смысл изменить его модификатор области действия на protected, если модификатор области излишне строгий. Защищенный доступ должен дать доступ вашим тестовым ресурсам (потому что ваш тест должен быть определен в том же пакете, что и тестируемый класс).

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

Похоже, вам нужен класс ServerConfigurationTest.java, который будет проверять чтение очень упрощенного файла Server.xml, а затем проверить, что вы правильно записали данные из этого файла.

Отдельно, вам нужен класс ServerServiceTest.java. Вы создадите макет любого класса ServerService для доступа к данным из Server.xml (предположительно ServerConfiguration). Отъезд the behavior page из их документации. Модифицированный, вы бы что-то вроде:

// create and populate testConfigServersList with test data 
    expect(configMock.getActiveServers()) 
    .andReturn(testConfigServersList); 

Поскольку вы вызываете метод напрямую, вам не нужно «запустить» нить. Класс junit уже будет выполнен. Вы просто устанавливаете состояние на некоторые тестовые объекты, запускаете метод, который вы тестируете, а затем проверяете состояние, измененное так, как вы ожидали.

У вас будет второй тест, который будет выглядеть одинаково, но ваши тестовые данные имеют только неактивные серверы, после чего вы убедитесь, что ни один сервер не был запущен. EasyMock позволит вам проверить, вызван ли метод в вашем классе, но фактически не позволяет запустить этот метод с помощью функции Partial Mocking. Таким образом, вы создадите частичный макет ServerService и изматываете метод, когда он фактически запускает другой сервер. Если ServerService имеет один гигантский метод, который считывает данные из ServerConfiguration и запускает новый сервер для каждого активного сервера, тогда вам нужно реорганизовать свой код и извлечь новый запуск сервера в отдельный метод.

+1

защищенные методы также являются областью охвата пакета, поэтому, если тестовый класс находится в том же пакете, что и код под tedsdt (но в другом источнике дерево) тест сможет вызвать защищенный метод – NamshubWriter

+0

@Jeff Neet Спасибо за ваши предложения. Но теперь я застрял в другой проблеме, и я обновил это в своем вопросе. Пожалуйста, взгляните на это. – user3473132

+0

@ user3473132 эта часть вашего кода является прекрасным примером того, где вы должны извлечь метод: ** Некоторые бизнес-логики ** Вы не хотите тестировать методы суперкласса в подклассе. Поэтому вместо этого создайте новый защищенный метод в том же классе, что и 'params()', который принимает две строки, 'integrity 'и' sWAnswer' в качестве аргументов. Затем вызовите новый метод непосредственно из вашего теста.Это позволяет вам указать известную строку, с которой вы можете надежно протестировать. Если вы позволите супер указать его, изменения в супер будут нарушать ваш тест. Это по определению НЕ является единичным тестом. –

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