Довольно понятный список желаний.Я думаю, что мы все ненавидим это в тестировании, когда сталкиваемся с зависимостями, которые делают тестирование бесполезным.Тесты должны быть простыми и короткими, и многое из того, что нужно решить до и после выполнения каждого теста, может быть обременительным.
Из описания вашего вопроса кажется, что вы довольно точно знаете, что ищете.
Моя первая реакция будет то, что вы используете PHPUnit для этого.Он не отвечает всем вашим требованиям, но это база, на которой вы можете строить.Он очень расходный и гибкий, однако он не поддерживает PSR-0, но имеет собственный автозагрузчик, так что, вероятно, это не так сложно.
Из информации, которую вы задаете в своем вопросе, я не уверен, чтодизайн вашего тестового набора (ов) или дизайн вашего приложения мешают написанию и выполнению тестов, которые вы бы хотели.
Я чувствую запах, вероятно, обоих.Если код вашего приложения нелегко тестировать, то такой среды тестирования, как PHPUnit, не так много.Так, например, если ваши контроллеры не используют объект запроса с интерфейсом, не так просто внедрить какой-либо запрос, который был вызван не запросом HTTP, а вашими тестами.Поскольку HTTP чаще всего является точкой входа в веб-приложение, здесь стоит абстрагироваться от тестов.Существуют некоторые предложения помимо конкретных фреймворков: Fig / Http .Однако это всего лишь указатель.
Похожий сценарий с базой данных, который вы даете: если код вашего приложения зависит от базы данных, то и ваши тесты тоже будут.Если вы не хотите постоянно тестировать свою базу данных, вам нужно, чтобы ваши контроллеры могли работать без конкретной базы данных.Это сравнимо с HTTP-запросами.
Существует множество подходов, чтобы справиться с этими обстоятельствами, но когда я читаю ваш вопрос, вы не выглядите необразованным, но скорее вы ищете лучшее решение, чем существующееединицы.
Как и в каждом собственном коде, довольно сложно найти что-то, что соответствует собственному дизайну.Лучшее предложение, которое я могу дать, - расширить PHPUnit, добавив в него те наборы и ограничения, которые вам необходимы для вашего приложения , в то время как вы используете поддержку автоматических тестов для рефакторинга вашего приложения в соответствии с вашими потребностями.test.
Таким образом, вы можете начать с тестов, а затем разработать контроллер так, как вам нужно.Это, как я полагаю, сохранит ваш контроллер на свету и поможет вам найти нужные решения.
Если вы найдете что-то, чего не хватает в PHPUnit, вы можете сначала расширить его самостоятельно, и, кроме того, автор очень помогает вдобавление отсутствующих функций.
Имейте в виду, что если не существует то, что вам нужно, вам нужно написать его самостоятельно.Однако, если вы можете поделиться (частично) работой с другими, вы чаще всего получаете выгоду, чем делая все в одиночку.Это точка для существующего фреймворка, будь то для тестирования или приложения.
Так что если на данный момент еще нет такого контроллера / MVC, который бы поддерживал простое модульное тестирование из коробки, которое соответствует вашим потребностям,вмешиваться и развивать один TDD-мудрый.Если все сделано правильно, это может точно соответствовать вашим требованиям.Однако я думаю, что вы не одиноки с этой проблемой.Так что не очень конкретный ответ, но я могу только сказать, что я получил очень хороший опыт работы с PHPUnit и его расширяемостью.Это включает в себя выходные тесты, которые вы упоминаете в своем вопросе.
И, возможно, небольшая разница в конце: одно дело - тестировать блоки кода, а другое - проверять, все ли они работают согласованно в приложении с различными запросами. Последнее чаще всего требует больших тестовых настроек по своей природе. Однако если вы можете отделить юниты друг от друга и четко определить, с какими другими блоками они взаимодействуют, то обычно вам нужно только протестировать взаимодействие между теми, которые могут уменьшить настройку. Это не спасает вас от проблем с инфраструктурой, но, как правило, они в любом случае не тестируются с юнит-тестами (хотя вы можете расширить PHPUnit для выполнения других типов проверок).
Популярный фреймворк - даже с плохим дизайном - имеет большой плюс в том, что компоненты, как правило, лучше тестируются при использовании. Обычно это помогает в течение первых лет вашего приложения, пока из-за проблем с дизайном в фреймворке вам не придется переписывать всю базу кода (вероятно).
Поскольку контроллеры часто сортируются в середине всего, это может привести к сценарию, в котором вы склонны тестировать все приложение, в то время как вы хотите тестировать только контроллеры. Поэтому вам следует подумать о дизайне и роли контроллеров и их месте в общем приложении, о том, что вы действительно хотите протестировать с вашими контроллерами, чтобы вы могли действительно сделать их тестируемыми в соответствии с вашими потребностями. Если вам не нужно тестировать базу данных, вам не нужно тестировать модели. Таким образом, вы можете смоделировать модель, возвращающую случайные данные, чтобы довести ее до крайности. Но если вы хотите проверить правильность обработки HTTP, то, вероятно, сначала необходим модуль, который абстрагирует обработку HTTP. Каждый контроллер, полагающийся на это, не понадобится для тестирования (теоретически), поскольку обработка HTTP уже была протестирована. Это также вопрос уровня абстракции. Не существует общего решения, это только то, что фреймворки могут что-то предложить, но тогда вы будете привязаны к тем парадигмам, которые ожидает фреймворк. AFAIK-тестирование в php становится все более популярным, но это не значит, что существующие фреймворки имеют хорошую поддержку. Я знаю из Zend Framework, что они работают над этим, чтобы улучшить ситуацию еще дольше. Так что, вероятно, стоит взглянуть на последние разработки в более популярных фреймворках, и к чему это приведет.
И для самых конкретных вещей, вы должны всегда тестировать самостоятельно.
Однако выбор PHPUnit и собственных тестовых сценариев выглядит практически для меня. Кодируйте свои контроллеры так, как вам нужно для вашего проекта в TDD, и вы должны получить то, что вам нужно.
Вероятно, более компонентный подход Symfony 2 лучше соответствует вашим потребностям, чем то, что вы испытали в Zend Framework. Тем не менее, я не могу предложить вам что-то конкретное, поскольку потребности сильно различаются в дизайне приложения. То, что быстрое и надежное решение для одного приложения является бременем для другого. См. Контроллер страниц .