存在被焚烧的风险......在上下文隐含的上下文中，强制执行对方法而不是函数的调用有什么优势。
考虑到PHP的语法对于调用方法来说是如此丑陋，为什么PHPUnit的创建者会强制使用它？
如果框架设置了一个全局“currentTestCase”对象，然后透明地将失败的断言与该对象相关联，那么我们可以写：
assertEquals("blah", $text);
而不是等同的，但是详细的：
$this->assertEquals("blah", $text);
在这种情况下，我们通过使用OO到底得到了什么。
请赐教。
答案 0 :(得分：6)
因为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比替代方案好得多。
答案 1 :(得分：3)
一个很好的理由是assertXXX作为方法名称具有命名冲突的高风险。
另一个是它来自 xUnit 系列，它通常处理面向对象的语言 - 最初是Smalltalk。这使您更容易将自己与您的“兄弟姐妹”联系起来，例如Java和Ruby。
答案 2 :(得分：2)
不是直接的答案，但从PHPUnit 3.5开始，您不必再编写$this->了。 PHPUnit 3.5为Assertions添加了一个函数库，你必须包含
require_once 'PHPUnit/Framework/Assert/Functions.php';
然后你可以做
assertEquals('foo', $bar);
请参阅Sebastian Bergmann关于它的博客文章
答案 3 :(得分：0)
在类方法中使用测试用例可以节省PHPUnit的工作量。由于缺乏内置智能，PHPUnit无法找到或处理纯测试功能。只需要识别 - ＆gt;断言*（）消息 - 在一个简单的布尔链中 - 再次保存处理逻辑（对于PHPUnit，而不是测试用例作者）。从PHPUnit / SimpleTest的角度来看，所有语法盐都可以节省开销。
捕获错误/警告消息，异常或识别PHP本机assert（）语句不是技术问题。它没有完成，因为一个困难的API看起来更加企业化。