Библиотека фронт-контроллера PHP с поддержкой модульного тестирования

Ответ 1

Зная Symfony2, я могу заверить, что это определенно возможно использовать его только для "C" в MVC. Модели и шаблоны полностью бесплатны и, как правило, выполняются с контроллеров, поэтому, если вы не называете Doctrine или Twig специально, вы можете делать то, что хотите.

Что касается функционального тестирования, на самом деле это то, о чем вы говорите в своей статье, то, что вы хотите посмотреть, это класс WebTestCase, который хорошо дополняется пакет LiipFunctionalTestBundle для более сложных случаев.

Это позволяет некоторым вещам, подобным этому примеру тестировать контактную форму, которая отправляет электронное письмо, где весь HTTP-запрос выполняется в процессе, поскольку структура написана для того, чтобы разрешить несколько запросов на один процесс и не имеет глобального состояния, это работает очень хорошо и не требует, чтобы сервер http работал или что-то еще. Как вы можете видеть, я тоже делаю утверждения в HTTP-статусе кода ответа и смог захватить электронную почту, не отправив ее, так как в тестовой конфигурации отправка писем отключен в стандартном дистрибутиве Symfony2.

При этом вы также можете просто использовать классы Request and Response из Symfony2 HttpFoundation. Это должно позволить вам протестировать ваш код, но IMO вы бы не получили столько полезных функций, сколько могли бы, если бы вы использовали всю инфраструктуру. Конечно, это просто мое предвзятое мнение;)

Ответ 2

Я бы порекомендовал загрузить компонент Framework Routing Symfony 2: https://github.com/symfony/Routing

Документация находится здесь: http://symfony.com/doc/current/book/routing.html

Возможно, он не удовлетворяет всем вашим требованиям, но он ближе всего.

Ответ 3

Если вы знакомы с symfony (который, я думаю, вы есть), вы должны проверить silex. С их сайта это то, что они говорят об этом: Микрофрейм предоставляет кишки для создания простых однофайловых приложений. Цель Silex:

• Краткий: Silex предоставляет интуитивно понятный и сжатый API, который очень полезен.
• Расширяемый: Silex имеет расширение система, основанная на микроскопе Pimple сервис-контейнер, что делает его даже легче связать стороннюю сторону библиотеки.
• Тестируемый: Silex использует Symfony2 HttpKernel, который реферат запрос и ответ. Это делает это очень легко протестировать приложения и самой рамки. Он также уважает спецификации HTTP и поощряет его надлежащее использование.

Ответ 4

Я бы добавил Net_URL_Mapper, однако он не имеет утверждений. Вот почему вы это исключили?

Еще одна интересная вещь - silex. Он также поставляется с проверкой контроллера. Я бы использовал это над Symfony2. Но это мое личное предпочтение.

Ответ 5

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

Из описания вашего вопроса, похоже, вы точно знаете, что ищете.

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

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

Я чувствую запах вроде обоих. Если ваш код приложения нелегко проверить, то не так много возможностей для тестирования, как PHPUnit. Например, если ваши контроллеры не используют объект запроса с интерфейсом, не так просто вставить некоторый запрос, который не был вызван HTTP-запросом, а вашими тестами. Поскольку HTTP чаще всего является точкой входа в веб-приложение, он платит за абстракцию здесь для тестов. Существуют некоторые предложения, помимо конкретных структур: Fig/Http. Однако это всего лишь указатель.

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

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

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

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

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

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

Итак, если до сих пор нет такого контроллера /MVC, который поддерживает легкое модульное тестирование из коробки, которое соответствует вашим потребностям, перезвоните и разработайте один TDD-мудрый. Если все сделано правильно, оно может точно соответствовать вашим требованиям. Однако я думаю, что вы не одиноки с этой проблемой. Так что не очень конкретный ответ, но могу только сказать, что я очень хорошо поработал с PHPUnit и его расширяемость. Это включает выходные тесты, которые вы упоминаете в своем вопросе.

И, вероятно, небольшое различие в конце: это одна вещь, чтобы протестировать блок кода, а другой проверить, все ли они работают вместе в приложении с ним различными запросами. Последнее чаще всего требует большей настройки тестов по своей природе. Однако, если вы можете отделить единицы друг от друга и четко определить, с какими другими единицами они взаимодействуют, вам обычно нужно только проверить взаимодействие между теми, которые могут уменьшить настройку. Это не избавляет вас от проблем с инфраструктурой, но, как правило, они не тестируются с помощью модульных тестов (хотя вы можете расширить PHPUnit для выполнения других типов проверок).

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

Поскольку контроллеры часто сортируются в середине всего, это может привести к тому, что вы склонны тестировать все приложение, пока вы хотите протестировать контроллер (ы). Поэтому вы должны подумать о дизайне и роли контроллеров и их месте в общем приложении, что вы действительно хотите протестировать с помощью ваших контроллеров, чтобы вы действительно могли сделать их проверяемыми в соответствии с вашими потребностями. Если вам не нужно тестировать базу данных, вам не нужно тестировать модели. Таким образом, вы можете издеваться над моделью, возвращающей случайные данные, чтобы довести ее до крайности. Но если вы хотите проверить правильность обработки HTTP, возможно, сначала потребуется единица, которая абстрагирует обработку HTTP. Каждый контроллер, полагающийся на это, не понадобится для тестирования (теоретически), поскольку обработка HTTP уже была протестирована. Это вопрос об уровне абстракции. Нет общего решения, это только те рамки, которые могут предложить что-то, но тогда вы привязаны к тем парадигмам, которые ожидают рамки. Тест AFAIK в php становится все более популярным, но это не значит, что существующие фреймворки имеют хорошую поддержку для него. Я знаю из структуры zend, что они работают над этим, чтобы улучшить ситуацию с тех пор. Поэтому, вероятно, стоит заглянуть в более поздние разработки в более популярных рамках того, к чему это приводит.

И по самой специфике вам нужно всегда тестировать самостоятельно.

Выбор PHPUnit и собственных тестовых файлов, однако, выглядит для меня практически способом. Содержите свои контроллеры так, как вам нужно, для своего проекта в TDD, и вы должны получить то, что вам нужно.

Вероятно, более основанный на компонентах подход Symfony 2 лучше подходит для ваших потребностей, чем то, что вы испытали с Zend Framework. Тем не менее, я не могу предложить вам ничего конкретного, поскольку потребности в дизайне приложений сильно различаются. То, что быстрое и надежное решение для одного приложения является бременем для другого. См. Контроллер страницы.

Ответ 6

Вы можете взглянуть на http://ezcomponents.org/ ведьма становится apache zeta​​p >

Существует три способа сделать компоненты eZ доступными для вашей среды PHP, пожалуйста, прочитайте всю эту статью, прежде чем продолжить практическую часть:

Use PEAR Installer for convenient installation via command line
Download eZ components packaged in an archive
Get the latest sources from SVN

У меня еще нет моих рук, но выглядит как хорошее решение...

Ответ 7

Seldaek: WebTestCase - это не совсем то, что нужно для проверки зрения напрямую, а контроллер или модель косвенно.

A unit test случай для контроллера вызовет контроллер, вероятно, даст ему макет объекта для механизма шаблонов (например, макет Smarty-объекта), затем проверьте значения, которые были назначены этому объекту для отображения: например, если вы вызываете контроллер для /countries/south -sudan, вы можете проверить, что для переменной шаблона $continent установлено значение "Африка". В большинстве случаев такой unit тест фактически не включал бы какой-либо рендеринг шаблонов.