Расширенное тестирование PHPUnit: аннотации и макеты

Ради примера я сократил это до оператора return. Видишь этот sleep я там бросил? Таким образом, мы можем легче сказать, что мы используем фиктивный объект вместо реального. Имитирует задержку в исполнении. Теперь самое интересное — тест.

Я объясню различные части после кода:

 <?php require_once '/path/to/Database.php'; class DatabaseTest extends PHPUnit_Framework_TestCase { private $db = null; public function setUp() { $this->db = new Database(); } public function tearDown() { unset($this->db); } /** * Test that the "really long query" always returns values */ public function testReallyLongReturn() { $mock = $this->getMock('Database'); $result = array( array(1,'foo','bar test') ); $mock->expects($this->any()) ->method('reallyLongTime') ->will($this->returnValue($result)); $return = $mock->reallyLongTime(); $this->assertGreaterThan(0,count($return)); } } ?> с <?php require_once '/path/to/Database.php'; class DatabaseTest extends PHPUnit_Framework_TestCase { private $db = null; public function setUp() { $this->db = new Database(); } public function tearDown() { unset($this->db); } /** * Test that the "really long query" always returns values */ public function testReallyLongReturn() { $mock = $this->getMock('Database'); $result = array( array(1,'foo','bar test') ); $mock->expects($this->any()) ->method('reallyLongTime') ->will($this->returnValue($result)); $return = $mock->reallyLongTime(); $this->assertGreaterThan(0,count($return)); } } ?> 

Здесь делается несколько новых звонков; проще всего обнаружить метод getMock в объект теста PHPUnit. Этот метод делает вызов для создания псевдо-версии рассматриваемого объекта. В этом случае создается фиктивный объект Database который мы можем использовать в нашем тесте.

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

В нашем длинном примере запроса мы создаем фиктивный объект и переопределяем метод reallyLongTime для наших собственных целей. Эти несколько строк являются реальным ключом:

 <?php $mock->expects($this->any()) ->method('reallyLongTime') ->will($this->returnValue($result)); ?> 

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

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

С функциональностью насмешки можно получить массу удовольствия, включая использование удобного MockBuilder . Это позволяет вам делать некоторые звонки, которые не делает базовый макет. В нашем примере ниже вы можете увидеть, как создать новый макет объекта, который не использует конструктор класса, а также отключить автозагрузку, которая может быть в работе:

 <?php public function testReallyLongRunBuilder() { $stub = $this->getMockBuilder('Database') ->setMethods(array( 'reallyLongTime' )) ->disableAutoload() ->disableOriginalConstructor() ->getMock(); $result = array(array(1,'foo','bar test')); $stub->expects($this->any()) ->method('reallyLongTime') ->will($this->returnValue($result)); $this->assertGreaterThan(0,count($return)); } ?> 

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

Есть также несколько других типов возврата, кроме returnValue . Вы можете получить значение, возвращаемое из функции обратного вызова (функция PHP или пользовательская), возвращать серию результатов при последовательных вызовах фиктивного объекта и даже выдавать исключение.

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

 <?php /** * Testing enforcing the type to "array" like the "enforceTypes" * method does via type hinting */ public function ttestReallyLongRunBuilderConstraint() { $stub = $this->getMock('Database',array('reallyLongTime')); $stub->expects($this->any()) ->method('reallyLongTime') ->with($this->isType('array')); $arr = array('test'); $this->assertTrue($stub->reallyLongRun($arr)); } ?> 

В этом случае тест будет reallyLongRun потому что я reallyLongRun с массивом (проверяется с помощью вызова isTyp e). Если бы я вызвал его на заглушку со строкой, PHPUnit выбросил бы ошибку.

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

Резюме

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

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

В руководстве по PHPUnit есть множество других интересных функций, ожидающих открытия. Вы можете сгенерировать документацию из своего теста с TestDox , интегрировать свое тестирование с Selenium и сгенерировать номера покрытия кода для своего приложения, чтобы указать вам, где именно вам нужно тестировать.

Оттуда вы можете перейти к таким понятиям, как проектирование на основе тестирования (упомянутое в предыдущей статье), которое может радикально изменить способ написания приложений.

Модульное тестирование — это удивительно мощный инструмент, а наличие программного обеспечения, такого как PHPUnit, делает его легким и приятным.