Заглушка и насмешка в PHPUnit в приложении Zend Framework

Question

Я новичок в Zend Framework и PHPUnit.Я преобразовываю устаревшее приложение в архитектуру MVC и пытаюсь написать модульные тесты.Я немного знаком с концепциями модульного тестирования, но застрял в тупиках и издевательствах в целом.Например, рассмотрим следующее

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

class A extends Zend_Controller_Action {
    public function viewAction() {
        $member = new Member($this->getRequest()-> getParam('id'));

        //perform various calls on the member object 

        $gender = $member->getGender();
        ...

        //assign the return values to the view object

        $this->view->assign('gender',$gender);   
        ...

     }
}

Как смоделировать переменную $ member в моих тестах, чтобы я мог настроить возвращаемые значения методов?

Если мое понимание здесь неверно, я был бы очень признателен за некоторые рекомендации.

Спасибо!

Answer 1

Если я вас правильно понимаю, вы пишете тест для этого действия. В этом случае невозможно смоделировать $ member, так как новый экземпляр создается внутри метода. Вот почему мы все стремимся разместить как можно больше наших new операторов на графе объектов (DI).

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

Но, на самом деле, очень сложно или даже невозможно правильно проверить контроллеры ZF (то есть с полной изоляцией). Вам лучше протестировать остальную часть вашего приложения, вашу общую библиотеку и т. Д.

Другими словами, в логике ZF1 контроллер является центральным местом подключения (после начальной загрузки), где традиционно используется множество операторов new. Очевидно, что это приводит к невозможности тестирования, поскольку каждый экземпляр, который создается, а не внедряется, не подлежит изменению.

Как отметил @vascowhite, также неплохо стремиться к экономным контроллерам. Это значит, перенести как можно больше логики на слой модели. Это приведет к меньшей избыточности (DRY) и одновременно лучшей тестируемости.

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

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

Итак, учитывая все это, ясно, что вы не можете достичь полной изоляции для своих тестов действий. Но

ZF2 будет намного проще тестировать.

Answer 2

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

Чтобы написать функциональные тесты с ZF, рассмотрите возможность использования Codeception: http://codeception.com/01-27-2012/bdd-with-zend-framework.html

Также есть несколько примеров того, как можно выполнить модульные тесты для контроллера.Но, искренне, я рекомендую модульное тестирование контроллеров после того, как функциональные тесты для них сделаны.

http://codeception.com/docs/06-UnitTestsAndBDD#TestingController