冒着被冒火的危險......在隱含上下文的上下文中，強制執行對方法調用而不是函數的優勢。爲什麼PHPUnit堅持做OO的方式？
考慮到PHP的語法對調用方法來說太難看了，爲什麼PHPUnit的創建者會強制使用它？
如果框架已經建立一個全球性的「currentTestCase」對象，然後透明的關聯未能與該對象，我們可以寫斷言：
assertEquals("blah", $text);
，而不是等價的，但詳細：
$this->assertEquals("blah", $text);
在這種情況下，我們通過使用面向對象得到了什麼。
請賜教。
因爲PHPUnit是從xUnit派生的，所以xUnit就是這麼做的。
爲什麼xUnit這樣做？我很高興你問。正如Robert指出的那樣，最初的原因是xUnit來自Smalltalk，並在Java中由JUnit推廣。兩者都是OO或沒有的語言，所以他們沒有選擇。
這並不是說沒有其他優點。面向對象測試可以被繼承。這意味着如果你想測試一個子類，你可以運行所有父級的測試，併爲你已更改的行爲覆蓋少數測試方法。這使您能夠很好地覆蓋子類而不必複製測試代碼。
它很容易添加和重寫PHPUnit中的斷言方法。只是子類PHPUnit_Framework_TestCase，編寫你自己的assert方法，讓你的測試類繼承你的新子類。您也可以編寫默認setup和teardown方法。
最後，它保證了測試框架的方法不會與他們正在測試的東西發生衝突。如果測試框架只是將其功能轉移到測試中，並且您想測試某種具有setup方法的東西......那麼您有麻煩了。
這就是說，我聽到你的痛苦。一個大的測試框架可能會令人討厭，麻煩而脆弱。 Perl不使用xUnit風格，它使用簡短測試函數名稱的過程風格。一個例子見Test::More。在幕後它按照你的建議做了，有一個單例測試實例對象，所有函數都使用它。還有一個稱爲Test::Class的OO測試方法模塊的混合程序斷言功能，它兼顧兩方面的優點。
考慮到PHP的語法是調用方法
我猜你不喜歡->這麼難看。我建議你學會和它一起生活。 OO PHP比替代方案好得多。
夠公平了，我同意擴展現有TestCases的想法，但是覆蓋斷言方法看起來很糟糕。作爲參考，我不反OO，只是在沒有必要的時候。感謝Test :: More鏈接+1 – 2009-06-01 20:40:03
不僅僅是重寫，而且還會根據需要添加自己的斷言。非常方便。例如，Drupal的SimpleTest分支沒有辦法斷言兩個數組是相等的，所以我寫了assertArrayEq（）。它的assertEquals（）缺少故障診斷，它只是說它們不相同，但我需要知道調試的值，所以我編寫了自己的assertEq（），它向我展示了值和調試的速度。 10年前，Perl程序員對OO非常謹慎，所以我認爲PHP社區即將出現。 ：P – Schwern 2009-06-02 01:18:21
一個很好的原因是作爲方法名稱的assertXXX對命名衝突有很高的風險。
另一個原因是它來自於xUnit系列，它最初處理面向對象的語言--Smalltalk。這使得你更容易將自己與你的「兄弟姐妹」聯繫起來。 Java和Ruby。
使用類方法中的測試用例可以節省PHPUnit的工作量。由於缺乏內置智能，PHPUnit無法找到或處理純粹的測試功能。只需要識別 - > assert *（）消息（在簡單的布爾鏈中），就可以節省處理邏輯（對於PHPUnit，而不是測試用例作者）。這些都是從PHPUnit/SimpleTest的角度來節省開銷的語法鹽分。
捕獲錯誤/警告消息，異常或識別PHP native native assert（）語句並不是一個技術問題。這沒有完成，因爲一個困難的API看起來更有企業性。
不是直接的答案，但是從PHPUnit 3.5開始，您不必再寫$this->了。 PHPUnit的3.5增加了斷言，你必須包括
require_once 'PHPUnit/Framework/Assert/Functions.php';
然後一個函數庫，你可以做
assertEquals('foo', $bar);
見塞巴斯蒂安伯格曼的博客文章吧
雖然這是我現在提供的問題的答案，但並不是當我問到它時。我會接受它，但是因爲任何想要在將來解決這個指針的人都可以使用它。 – 2010-11-18 14:50:52
你主張使用全球？ – Robert 2009-06-01 19:24:52
是的，我想我是，但在嚴格的情況下。好的，現在你讓我覺得很骯髒。 – 2009-06-01 20:47:36
你能否請你回顧一下你現在給出的答案，並接受最有幫助的問題，或者細化你的問題，注意爲什麼沒有答案能爲你解決問題。謝謝。 – Gordon 2010-11-11 11:20:44