Почему PHPUnit настаивает на том, чтобы делать вещи ОО?

Question

С риском быть воспламененным ... какое преимущество дает принудительное обращение к методам, а не к функциям, в контексте, где контекст неявный.

Учитывая, что синтаксис PHP настолько уродлив для вызова методов, почему создатели PHPUnit принудили его использовать?

Если инфраструктура установила глобальный объект «currentTestCase», а затем прозрачно связала неудачные утверждения с этим объектом, мы могли бы написать:

assertEquals("blah", $text);

в отличие от эквивалента, но многословно:

$this->assertEquals("blah", $text);

Что именно мы получаем, используя ОО в этом контексте.

Пожалуйста, просветите меня.

Answer 1

Поскольку PHPUnit является производным от xUnit, и именно так xUnit делает это.

Почему xUnit делает это так? Я рад, что ты спросил. Первоначальная причина, как указывает Роберт, заключается в том, что xUnit происходит от Smalltalk и популяризируется JUnit на Java. Оба являются языками с нулевым или нулевым уровнем, поэтому у них не было выбора.

Это не значит, что нет других преимуществ. ОО тесты могут быть унаследованы. Это означает, что если вы хотите протестировать подкласс, вы можете запустить все родительские тесты и просто переопределить несколько тестовых методов для поведения, которое вы изменили. Это дает вам превосходное покрытие подклассов без дублирования тестового кода.

Его легко добавлять и переопределять методы assert в PHPUnit. Просто создайте подкласс PHPUnit_Framework_TestCase, напишите свои собственные assert методы, и ваши тестовые классы наследуют от вашего нового подкласса. Вы также можете написать методы по умолчанию setup и teardown.

Наконец, это гарантирует, что методы тестовой среды не будут конфликтовать с тем, что они тестируют. Если тестовый фреймворк просто выбросил свои функции в тест, и вы хотите протестировать что-то с setup методом ... ну, у вас проблемы.

Тем не менее, я слышу вашу боль. Большой тестовый фреймворк может быть раздражающим, громоздким и ломким. Perl не использует стиль xUnit, он использует процедурный стиль с короткими именами тестовых функций. См. Test :: More для примера. За кулисами он делает именно то, что вы предложили, есть объект экземпляра одиночного теста, который используют все функции. Есть также гибридные процедурные функции утверждения с модулем методов тестирования OO под названием Test :: Class , который делает лучшее из обоих миров.

Учитывая, что синтаксис PHP настолько уродлив для вызова методов

Полагаю, вам не нравится ->. Я предлагаю вам научиться жить с этим. OO PHP намного лучше, чем альтернатива.

Answer 2

Одна веская причина в том, что assertXXX в качестве имени метода имеет высокий риск для конфликта имен.

Еще одно, это то, что оно происходит от семейства xUnit , которое обычно работает с объектно-ориентированными языками - изначально Smalltalk. Это облегчает связь с вашими "братьями и сестрами", например, с. Java и Ruby.

Answer 3

Не прямой ответ, но начиная с PHPUnit 3.5 вам больше не нужно писать $this->. В PHPUnit 3.5 добавлена ​​библиотека функций для утверждений, в которую нужно включить

require_once 'PHPUnit/Framework/Assert/Functions.php';

Тогда вы можете сделать

assertEquals('foo', $bar);

См. Сообщение в блоге Себастьяна Бергмана об этом

.

• http://sebastian -bergmann.de / архив / 896-PHPUnit-3,5-Less-это-Required.html # содержание

Answer 4

Наличие тестовых примеров в методах класса экономит работу для PHPUnit. Из-за отсутствия встроенного интеллекта PHPUnit не смог найти или обработать чистые тестовые функции. Только необходимость распознавать сообщения -> assert * () - в простой логической цепочке - снова сохраняет логику обработки (для PHPUnit, а не автора тестового примера). Это все синтаксическая соль, которая экономит накладные расходы с точки зрения PHPUnit / SimpleTest.

Не будет технической проблемой перехватывать сообщения об ошибках / предупреждения, исключения или распознавать PHP-оператор assert (). Это не сделано, потому что сложный API выглядит более корпоративно.