Я пишу приложение Zend Framework и модуль, тестирующий его с помощью PHPUnit. В общем, все идет плавно, но у меня небольшая, но раздражающая проблема с PHPUnit и охватом кода – иногда мне говорят, что определенная строка не проверена, и я не знаю, как заставить ее тестироваться.
В следующем коде, например, я запускаю два теста: один с запросом GET, один с запросом POST. Тест проходит, и все в порядке. Однако, когда я смотрю на покрытие кода, это показывает мне, что строка «else» не выполняется.
public function editAction() { if ($request->isPost()) { // do actions related to POST } else { // do action related to GET } } Есть идеи? Как побочный вопрос, вы обычно упорствуете с модульными тестами, пока не получите 100% -ный охват кода? Или это не очень практично?
Большое спасибо …
Код, который у вас есть только для комментариев, имеет значение. Закрывающая скобка блока будет показана как исполняемая в отчете о покрытии кода, если можно проскочить до конца. Найдите ветку, которую вы на самом деле не проверяете.
if ($request->isPost()) { if ($x < 5) { return '<'; } elseif ($x > 5) { return '>'; } // Do you have a test for $x == 5? }
Что касается цели покрытия 100% кода, я полностью согласен с Биллом. Для некоторых классов классов, которые я пишу, я буду стремиться сделать 100%, но я знаю, что это не значит, что я действительно проверял каждую возможность. Часто, когда я нахожу себя слишком тяжело, чтобы достичь 100% -ного охвата, возможно, это OCD. 🙂
Просто . , , один . , , Больше . , , контрольная работа . , ,
Я был руководителем проекта на Zend Framework несколько лет назад, выпуском ZF 1.0. Я довольно много работал над повышением охвата тестирования для всех компонентов, и у нас была политика, согласно которой компонент должен иметь определенный минимальный охват кода, который должен быть принят в ZF из инкубатора.
Тем не менее, вы правы, пытаясь получить 100% -ый охват кода от тестов для всех ваших классов, не очень практичны. Некоторые из классов в ZF имеют 100% -ный охват, но для них справедливо одно или несколько из следующих утверждений:
Но мы также поняли, что 100% -ый охват кода иногда является искусственной целью. Тем не менее, набор тестов, который обеспечивает менее 100% -ный охват загара, может быть адекватным. И набор тестов, который доходит до 100% покрытия, не обязательно гарантирует качество.
Было бы очень легко получить 100% -ный охват кода для следующей функции. Но проверили ли мы деление на ноль?
function div($numerator, $denominator) { return $numerator / $denominator; }
Поэтому вы должны использовать охват кода как один показатель тестирования, но не конечную цель.
Если это все, что есть в вашем тесте, я бы предположил, что ваши тесты выглядят так, как сказал Матфей :
class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase { // [...] public function testSomething() { $this->request ->setMethod('POST') ->setPost(array( 'username' => 'foobar', 'password' => 'foobar' )); $this->editAction(); // assertThatTheRightThingsHappend } }
и в этом случае я не вижу причин, по которым не должно быть легко получить 100% покрытие кода.
Но да: довольно сложно тестировать контроллеры Zend Framework, и в какой-то момент вам нужно либо очень стараться, чтобы получить всю вашу логику приложения из контроллеров или просто жить с ним.
То же самое относится и к вашим моделям. Те, которые должны быть очень легко протестированы, даже в приложении ZF.
Цель, которую охватывает код, заключается в том, что она сообщает вам, какие части вашей базы кода даже не выполняются . Это не говорит вам, что действительно проверено, и может служить лишь «минимумом», чтобы получить представление о качестве вашего набора тестов (если вы не используете @covers, даже если это может вам помочь).
Вкратце: если у вас есть большие контроллеры и не так просто изменить архитектуру, просто устанавливая так называемые проверенные контроллеры, но не применяйте ту же логику к вашим моделям. Ничто в ZF не позволяет вам правильно протестировать эти