1

冒着被激怒的风险......在上下文是隐式的上下文中，强制调用方法而不是函数有什么好处。

考虑到 PHP 的语法对于调用方法来说是如此丑陋，为什么 PHPUnit 的创建者会强制使用它呢？

如果框架设置了一个全局“currentTestCase”对象，然后将失败的断言与该对象透明地关联起来，我们可以编写：

assertEquals("blah", $text);

与等价的相反，但冗长：

$this->assertEquals("blah", $text);

在这种情况下使用 OO 到底能得到什么。

请赐教。

4

4 回答 4

6

因为 PHPUnit 是从 xUnit 派生的，而 xUnit 就是这样做的。

为什么 xUnit 会那样做？我很高兴你问。正如 Robert 指出的那样，最初的原因是 xUnit 来自 Smalltalk，并被 Java 中的 JUnit 推广。两者都是 OO-or-nothing 语言，所以他们别无选择。

这并不是说没有其他优势。OO 测试可以被继承。这意味着如果你想测试一个子类，你可以运行所有父类的测试，并为你改变的行为覆盖少数测试方法。这为您提供了出色的子类覆盖率，而无需复制测试代码。

它很容易在 PHPUnit 中添加和覆盖断言方法。只需子类PHPUnit_Framework_TestCase，编写您自己的assert方法并让您的测试类从您的新子类继承。您还可以编写默认值setup和teardown方法。

最后，它保证测试框架的方法不会与他们正在测试的东西发生冲突。如果测试框架只是将其功能转储到测试中，并且您想测试具有setup方法的东西……那么您就有麻烦了。

也就是说，我听到了你的痛苦。一个大的测试框架可能是烦人的、麻烦的和脆弱的。Perl 不使用 xUnit 样式，它使用带有简短测试函数名称的过程样式。有关示例，请参见测试::更多。在幕后它只是按照您的建议进行操作，有一个所有函数都使用的单例测试实例对象。还有一个混合过程断言函数与称为Test::Class的 OO 测试方法模块，它做到了两全其美。

考虑到 PHP 的语法对于调用方法来说是如此丑陋

我猜你不喜欢->. 我建议你学会忍受它。OO PHP 比替代方案好得多。

于 2009-06-01T20:35:23.427 回答
3

一个很好的理由是，assertXXX作为方法名称，命名冲突的风险很高。

另一个是它源自xUnit家族，该家族通常处理面向对象的语言——最初是 Smalltalk。这使您更容易将自己与来自例如 Java 和 Ruby 的“兄弟姐妹”联系起来。

于 2009-06-01T20:20:27.793 回答
2

不是直接的答案，但从 PHPUnit 3.5 开始，您不必再编写$this->了。PHPUnit 3.5 为断言添加了一个函数库，你必须包含它

require_once 'PHPUnit/Framework/Assert/Functions.php';

然后你可以做

assertEquals('foo', $bar);

请参阅 Sebastian Bergmann 的博客文章

于 2010-10-07T11:39:05.940 回答
0

将测试用例放在类方法中可以节省 PHPUnit 的工作量。由于缺乏内置智能，PHPUnit 无法找到或处理纯测试函数。只需识别 ->assert*() 消息 - 在一个简单的布尔链中 - 再次保存处理逻辑（对于 PHPUnit，而不是测试用例作者）。从 PHPUnit/SimpleTest 的角度来看，这都是节省开销的语法盐。

捕获错误/警告消息、异常或识别 PHP 原生的 assert() 语句都不是技术问题。它没有完成，因为一个困难的 API 看起来更企业化。

于 2010-10-07T05:23:16.000 回答