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

Это означает, что контроллер является компонентом высокого уровня. Чаще всего это указывает на то, что функциональные тесты в порядке, а не модульные тесты. Вы не должны стремиться получить 100% покрытие кода своими модульными тестами. Может быть, вы можете думать об этом так: если вы выполняете модульное тестирование всего, что вызывает контроллер (модель, проверка, форма, репозиторий), что может пойти не так? В большинстве случаев это то, что вы наблюдаете только при использовании всех реальных классов, задействованных в производстве.

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

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

Поэтому я предлагаю использовать функциональные тесты для тестирования ваших контроллеров и использовать модульные тесты для тестирования ваших моделей и вашей бизнес-логики.

Если вы боретесь с функциональными тестами, вы можете прочитать следующее:

• http://symfony.com/doc/current/book/testing.html#functional-tests< /а>
• http://blog.sznapka.pl/полностьюизолированные-тесты-в-симфонии2/

Используйте макеты, чтобы изолировать модели и другие объекты от логики основного метода контроллера, см. http://www.phpunit.de/manual/3.7/en/test-doubles.html#test-doubles.mock-objects

Я думаю, что в более старых версиях вы могли издеваться над всем классом, но с последней версией phpunit 3.6.10, которая у меня есть, это не работает. Итак, я думаю, у вас остался шаблон инъекции зависимостей

class objss{
    function ss(){
        $x = new zz();
        var_dump($x->z());
    }
}



class MoTest extends PHPUnit_Framework_TestCase{
    public function setUp(){

    }

    public function testA(){
        $class = $this->getMock('zzMock', array('z'), array(), 'zz');
        $class->expects($this->any())->method('z')->will($this->returnValue('2'));

        $obj = new objss();
        $this->assertEquals('2', $obj->ss());
    }
}

Модульное тестирование

Преобразуйте ваши контроллеры в сервисы: http://symfony.com/doc/current/cookbook/controller/service.html

Затем вы можете легко протестировать их.

Функциональное тестирование

Конечно (как уже упоминалось другими) вы можете использовать WebTestCase, как описано здесь: http://symfony.com/doc/current/book/testing.html#functional-tests

Льюис – Я решил прыгнуть сюда. Приведенный выше подход позволяет вам воспроизвести лучшую часть логики ваших действий в ваших тестах. В этом нет ничего плохого, многие фреймворки (особенно RSPEC в Rails) на самом деле предлагают вам выполнять как модульные тесты на ваших объектах контроллера, так и функциональные тесты. Однако, учитывая ваш пример, я думаю, что пропущу модульный тест и выберу функциональный подход.

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

https://github.com/PolishSymfonyCommunity/SymfonyMockerContainer

Отлично сработало для меня :)