我正在寻找一个(小型)库,该库可以帮助我为宠物项目完全实现前端控制器,并将请求分派给单个控制器类。前端控制器/调度程序和控制器类需要完全可单元测试,而不发送HTTP请求。
要求
兼容PSR-0
可通过自己的PEAR通道安装
支持单元测试:
检查是否发送了正确的HTTP标头
捕获输出以允许在单元测试中进行检查
PHPUnit辅助方法可帮助检查输出(对于不同的输出类型,即HTML,XML,JSON)
允许设置传入的HTTP标头,GET和POST参数以及cookie,而无需实际执行HTTP请求
需要可以独立使用-无需db抽象,模板化,以便胖框架都能提供
背景
SemanticScuttle是必须获得适当的" C"支持的应用程序,它是一个现有的可运行应用程序。该库需要融入其中,并且需要使用现有的结构和类。我不会重写它来匹配框架的特定必需目录布局。
该应用程序已经具有单元测试,但是基于HTTP请求,这会使它们变慢。同样,在www目录中具有数十个.php文件的当前旧方法也不是最易于管理的解决方案,这就是为什么需要引入适当的控制器类的原因。总共将有大约20-30个控制器。
以往的经验
总的来说,对于以前的一些项目,我对Zend Framework感到非常满意,但是它有几个缺点:
无法安装在pear上,因此无法在pear可安装的应用程序中将其用作依赖项
仅作为一次胖下载提供,因此对于每个ZF更新,我都需要手动从中提取所需的位。
尽管对ZF控制器存在单元测试支持,但它缺少一些高级实用程序功能,例如json的断言,HTTP状态代码和内容类型检查。
虽然这些观点似乎有些挑剔,但对我来说很重要。如果必须自己实现它们,则无需使用外部库,而可以编写自己的库。
我不想要的
StackOverflow有上百万个"什么是最好的PHP框架"问题(1、2、3、4、5),但是我不是在寻找这些问题,而是在寻找有助于控制器的特定库。如果它是模块化框架的一部分,那就好。
我也知道PHP框架比较网站,但是因为我的要求未在此处列出,所以它无助于回答我的问题。
而且我知道我可以自己构建所有这些,并发明另一个微框架。但为什么?他们已经有很多了,而其中一个就必须拥有我所需要的全部。
相关问题
您的"无框架" PHP框架是什么?
如何将基于页面的PHP应用程序转换为MVC?
not pear-installable那又如何?许多发行版都有用于维护当前安装版本的软件包。 only available as one fat download-再说一遍,那又如何呢?您只需下载并安装一次。 its lacking some advanced utility functionality使用您自己的扩展基本测试类并添加其他断言很容易。
@zerkms:我不会安装一次。我需要升级和维护它。拥有梨渠道可以帮助那里。
@cweiske:每个Linux发行版都在其软件包中包含它。您使用哪个?顺便说一句,使用梨,您还可以下载一发一收的文件。
@zerkms:"有了梨,您还可以下载一个完整的文件"-是的,这就是一个问题,因为ZF不在单独的模块中提供。您会看到我的问题:)此外,该软件还应可在OSX和Windows上安装。
@cweiske:您需要编写:在要测试不带HTTP请求时"检查是否发送了正确的HTTP标头"。我认为这行不通。您至少需要模仿请求标头才能执行此类测试。
@hakre:或具有一个"响应"对象,该对象封装了可发送的报头发送。
@cweiske:封装各种内容。通过接口使用对象进行请求和响应是一种快速实现对象的方法,尤其是在您的应用程序不那么复杂的情况下。您有几个控制器?
我非常了解Symfony2,可以向您保证,可以将其仅用于MVC中的" C"。这些模型和模板是完全免费的,并且通常无论如何都可以从控制器执行,因此,如果您不专门调用Doctrine或Twig,则可以执行所需的操作。
至于功能测试,这实际上是您在文章中所谈论的,您要查看的是WebTestCase类,该类由LiipFunctionalTestBundle捆绑包进行了很好的补充,可以用于更高级的案例。
这允许进行某些测试,例如测试发送电子邮件的联系表单的示例,其中整个HTTP请求都在过程中完成,因为该框架被编写为允许每个过程有多个请求并且没有全局状态,所以效果很好,并且不需要运行http服务器或其他任何东西。如您所见,我也对响应的HTTP状态代码进行断言,并且能够在不发送电子邮件的情况下捕获电子邮件,因为在测试配置中,Symfony2的标准发行版中已禁止发送电子邮件。
话虽如此,您也可以只使用Symfony2的HttpFoundation组件中的Request和Response类。它应该允许您测试代码,但是IMO如果使用整个框架,您将无法获得尽可能多的出色功能。当然那只是我的偏见;)
如果您熟悉symfony(我认为是),则应该从他们的网站上查看silex,这是他们对此的评价:
微框架为构建简单的单文件应用程序提供了勇气。 Silex的目标是:
简洁:Silex展现直观
简洁有趣的API。
可扩展:Silex具有扩展名
基于Pimple micro的系统
使它变得均匀的服务容器
更容易加入第三方
库。
可测试:Silex用途
Symfony2的HttpKernel抽象
请求和回应。这使它
非常容易测试的应用程序和
框架本身。它也尊重
HTTP规范并鼓励
正确使用。
我第二次。 WebTestCase非常酷。
我建议下载Symfony 2框架路由组件:https://github.com/symfony/Routing
可在以下位置找到文档:http://symfony.com/doc/current/book/routing.html
也许它不能满足您的所有要求,但它是最接近的。
我将添加Net_URL_Mapper,尽管它没有断言。这就是为什么您排除它?
另一个非常有趣的东西是silex。它还带有控制器测试。我会在Symfony2上使用它。但这是我的个人喜好。
Seldaek:WebTestCase不太正确-它是用于直接测试视图,并且仅用于间接测试控制器或模型。
控制器的单元测试用例将调用该控制器,可能会给它一个用于模板引擎的模拟对象(例如,模拟Smarty对象),然后检查分配给该对象以供显示的值:例如,如果您调用了/ countries / south-sudan的控制器,您可以检查模板变量$ continent是否设置为"非洲"。在大多数情况下,这种单元测试实际上不会涉及任何模板渲染。
您可以看看http://ezcomponents.org/女巫正在成为apache zeta
有三种方法使eZ组件可用于您的PHP环境,在继续实际部分之前,请阅读本文全文:
Use PEAR Installer for convenient installation via command line
Download eZ components packaged in an archive
Get the latest sources from SVN
我还没有开始尝试,但看起来是个不错的解决方案...
很容易理解的愿望清单。我认为当我们遇到导致测试崩溃的依赖项时,我们都讨厌测试。测试应该简单,简短,在运行每个测试之前和之后要解决很多问题,这可能是一个负担。
从问题的描述中,您似乎可以很明确地知道要查找的内容。
我的第一反应是为此使用PHPUnit。它不能满足您的所有要求,但可以作为基础。它具有很高的消耗性和灵活性,但是它不支持PSR-0,但是拥有它自己的自动加载器,因此可能没有那么重。
根据您在问题中提供的信息,我不确定测试套件的设计或应用程序的设计是否会妨碍编写和执行您希望执行的测试。
我闻到两种气味。如果您的应用程序代码不容易测试,那么没有像PHPUnit这样的测试框架可以做。因此,例如,如果您的控制器未将请求对象与接口一起使用,则注入并非由HTTP请求触发但由测试触发的请求并非易事。由于HTTP通常是Web应用程序的切入点,因此在这里进行测试摘要是值得的。除了特定的框架外,还有一些建议:Fig / Http。但是,这只是一个指针。
您提供的数据库方案与此类似:如果您的应用程序代码取决于数据库,那么您的测试也将如此。如果您不想一直对数据库进行测试,则需要使控制器能够在不使用具体数据库的情况下工作。这与HTTP请求相当。
有许多方法可以应对这些情况,但是当我读到您的问题时,您似乎并没有受到过教育,但与现有的方法相比,您正在寻找的是更好的解决方案。
与每个自己的代码一样,很难找到与自己的设计匹配的东西。我能提供的最好建议是扩展PHPUnit,以在使用自动化测试的支持来重构应用程序以适应您的测试需求时,为应用程序添加这些套件和约束。
因此,您可以从测试开始,然后根据需要开发控制器。我认为这将使您的控制器保持轻巧,并帮助您找到所需的解决方案。
如果发现PHPUnit缺少某些内容,则可以先自行扩展它,此外,作者在添加缺少的功能方面非常有帮助。
请记住,如果不存在所需的内容,则需要自己编写代码。但是,如果您能够与他人共享(部分)工作,那么与单独完成所有工作相比,您通常会获得收益。这是现有框架的重点,无论是用于测试还是用于应用程序。
因此,如果到目前为止还没有这样的控制器/ MVC能够支持符合您需要的即开即用的简单单元测试,请加入并开发一种TDD。如果操作正确,它可以完全满足您的要求。但是我认为您并不孤单。因此,这不是一个非常具体的答案,但是我只能说我在PHPUnit及其扩展性方面取得了很好的经验。这包括您在问题中提到的输出测试。
最后可能会有一点区别:测试代码单元是一回事,而测试它们是否在应用程序中都能满足各种请求则是另一回事。最后,通常情况下自然需要更大的测试设置。但是,如果您可以将各个单元彼此分开并明确定义它们与其他单元交互,那么通常只需要测试它们之间的交互即可减少设置。这不能使您摆脱基础结构问题,但通常无论如何都不会使用单元测试来测试这些问题(尽管您可以扩展PHPUnit来执行其他类型的检查)。
一个流行的框架-即使设计很差-也具有很大的优点,即组件往往会通过使用进行更好的测试。通常,这有助于遍历应用程序的最初几年,直到框架中的设计问题使您需要(可能)重写整个代码库。
由于控制器通常位于所有事物的中间,这可能导致您倾向于只测试控制器而往往测试整个应用程序的情况。因此,您应该考虑控制器的设计和作用以及它们在整个应用程序中的位置,您真正想对控制器进行测试的内容,这样才能真正根据需要对它们进行测试。如果您不需要测试数据库,则无需测试模型。因此,您可以模拟返回随机数据的模型以将其推向极限。但是,如果您要测试HTTP处理是否正确,则可能首先需要一个抽象HTTP处理的单元。从理论上讲,不需要依赖于此的每个控制器进行测试,因为已经对HTTP处理进行了测试。这也是抽象水平的问题。没有整体解决方案,只是框架可以提供某些东西,但是您就必须遵守框架期望的那些范式。 php中的AFAIK测试正变得越来越流行,但这并不意味着现有框架对此提供了良好的支持。我从zend框架知道,他们将在更长的时间里致力于改善这种情况。因此,有可能值得研究一下更流行的框架中的最新发展。
对于特定细节,您需要始终自己进行测试。
对我来说,选择PHPUnit和自己的测试用例确实是一种切实可行的方法。 在TDD中为您的项目编码所需的控制器时,您应该得到所需的东西。
与使用Zend Framework相比,Symfony 2的基于组件的方法可能更适合您的需求。 但是,我不能建议您使用任何特定的东西,因为应用程序设计中的需求差异很大。 对于一个应用程序来说,一种快速而可靠的解决方案对另一个应用程序来说是一个负担。 请参阅页面控制器。
好。
最后一段可能应标记为" TLDR"部分。
是的,无论如何,评论多于答案。 textwalling下午;)