Как выполнить тестирование метода, который ничего не возвращает с помощью phpunit [duplicate]

Изменить - с Apache Commons 2.1 правильный способ сделать это:

  FileUtils.writeStringToFile (файл, «String to append», true);   

Я адаптировал решение @ Kip, чтобы включить правильное закрытие файла, наконец: public static void appendToFile (String targetFile, String s) throws IOException {appendToFile (новый файл (targetFile), с); } public static void appendToFile (File targetFile, String s) throws IOException {PrintWriter out = null; try {out = new PrintWriter (новый BufferedWriter (новый FileWriter (targetFile, true))); out.println (ы); } finally {if (out! = null) {out.close (); }}}

17
задан GordonM 19 January 2012 в 17:42
поделиться

4 ответа

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

15
ответ дан Community 15 August 2018 в 17:20
поделиться
  • 1
    Если есть какой-то способ уловить ошибки, подобные описанным в вопросе, я хотел бы знать, что это такое. – GordonM 20 January 2012 в 09:26
  • 2
    @GordonM Разве ваша IDE не показывает $ mame как неиспользованный? – vascowhite 21 January 2012 в 00:29
  • 3
    @vascowhite: Кажется нет (Netbeans 7.0) – GordonM 21 January 2012 в 08:51
  • 4
    @GordonM Я расширил вопрос, немного показывая инструмент, который может помочь вам найти эти проблемы – edorian 21 January 2012 в 09:40
15
ответ дан Community 5 September 2018 в 16:25
поделиться

Вы также можете использовать Assert::assertAttributeEquals('value', 'propertyName', $object).

См. https://github.com/sebastianbergmann/phpunit/blob/3.7/PHPUnit/Framework/Assert.php#L490

33
ответ дан Gildas 15 August 2018 в 17:20
поделиться
  • 1
    Или используйте Assert::readAttribute($actualClassOrObject, $actualAttributeName), который используется Assert::assertAttributeEquals() – D. Schreier 5 July 2018 в 11:57

Я просто хочу отметить одно. Давайте забудем о частных полях на мгновение и сосредоточимся на том, что заботит клиент вашего класса. Ваш класс предоставляет контракт, в данном случае - возможность изменять и получать имя (через getter и setter). Ожидаемая функциональность проста:

  • , когда я задал имя с setName до "Gerald", я ожидаю получить "Gerald", когда я вызываю getName

Вот и все. Клиент не будет (ну, не стоит!) Заботиться о внутренней реализации. Используете ли вы имя частного поля, hashset или называете веб-сервис через динамически сгенерированный код - не имеет значения для клиента. ошибка , которую вы в настоящее время испытываете, с точки зрения пользователя - вообще не является ошибкой.

Может ли PHPUnit проверять частные переменные - я не знаю.

Редактировать (в ответ на комментарий):

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

2
ответ дан k.m 15 August 2018 в 17:20
поделиться
  • 1
    Вы правы, что в случае чести контракта класс работает как рекламируемый. Независимо от того, выполняет ли класс обещания, которые он делает, это то, что тест PHPUnit с черным ящиком обычно можно легко заметить. Проблема заключается в том, что, пока контракт API выполнен, возникла потенциальная серьезная проблема (непреднамеренное воздействие внутреннего состояния). Это то, что требует "стеклянной коробки" или " белый ящик " тесты, чтобы поймать (и вот как я отметил вопрос) – GordonM 19 January 2012 в 18:15
  • 2
    Благодаря! Я спускался в эту кроличью нору. – eggmatters 14 November 2015 в 00:51
Другие вопросы по тегам:

Похожие вопросы: