存在被焚烧的风险......在上下文隐含的上下文中,强制执行对方法而不是函数的调用有什么优势.
考虑到PHP的语法对于调用方法来说是如此丑陋,为什么PHPUnit的创建者会强制使用它？
如果框架设置了一个全局"currentTestCase"对象,然后透明地将失败的断言与该对象相关联,那么我们可以编写:
assertEquals("blah", $text);
而不是等同的,但冗长的:
$this->assertEquals("blah", $text);
在这种情况下,我们通过使用OO到底得到了什么.
请赐教.
因为PHPUnit的是从衍生的xUnit,这就是如何的xUnit做的.
为什么xUnit会这样做？我很高兴你问.正如罗伯特指出的那样,最初的原因是xUnit来自Smalltalk并且在Java中被JUnit推广.两者都是OO或非语言,因此他们别无选择.
这并不是说没有其他优点.OO测试可以继承.这意味着如果您想测试一个子类,您可以运行所有父级测试,并为您已更改的行为覆盖少数几种测试方法.这为您提供了极好的子类覆盖,而无需复制测试代码.
它很容易在PHPUnit中添加和覆盖断言方法.只需子类PHPUnit_Framework_TestCase,编写自己的assert方法,让测试类继承自新的子类.您还可以编写默认值setup和teardown方法.
最后,它保证了测试框架的方法不会与他们正在测试的东西冲突.如果测试框架只是将其功能转移到测试中,并且您想测试具有某种setup方法的东西......那么您就遇到了麻烦.
那就是说,我听到了你的痛苦.一个大的测试框架可能令人烦恼,麻烦和脆弱.Perl不使用xUnit样式,它使用具有短测试函数名称的过程样式.有关示例,请参见Test :: More.在幕后它完全按照你的建议,有一个单独的测试实例对象,所有函数都使用它.还有一个混合程序断言函数,其中包含名为Test :: Class的 OO测试方法模块,它可以实现两全其美.
考虑到PHP的语法对于调用方法来说是如此丑陋
我猜你不喜欢->.我建议你学会忍受它.OO PHP比其他选择更好.