PHPUnit-閱讀總結

簡介

PHPUnit是一個面向PHP程序員的測試框架，這是一個xUnit的體系結構的單元測試框架。

安裝

通常composer安裝

composer require phpunit/phpunit
複製代碼

編寫 PhpUnit 測試

測試的依賴關係

用 @depends 標註來表達依賴關係（DependTest.php）

數據供給器

用 @dataProvider 標註來表達數據供給器（AdditionProviderTest.php） 同一個測試中組合使用 @depends 和 @dataProvider（DependencyAndDataProviderComboTest.php）

對異常進行測試

用 @expectException 標註來測試被測代碼中是否拋出了異常（ExceptionTest.php）

對輸出進行測試

用 expectOutputString() 方法來設定所預期的輸出

方法	含義
void expectOutputRegex(string $regularExpression)	設置輸出預期爲輸出應當匹配正則表達式 $regularExpression。
void expectOutputString(string $expectedString)	設置輸出預期爲輸出應當與 $expectedString 字符串相等。
bool setOutputCallback(callable $callback)	設置回調函數，用來作諸如將實際輸出規範化之類的動做。

命令行測試執行器

手冊只是列出了phpunit --help，本身看吧

基境(fixture)

在編寫測試時，最費時的部分之一是編寫代碼來將整個場景設置成某個已知的狀態，並在測試結束後將其復原到初始狀態。這個已知的狀態稱爲測試的基境(fixture)。

通常操做

PHPUnit 支持共享創建基境的代碼。在運行某個測試方法前，會調用一個名叫 setUp() 的 模板方法。setUp() 是建立測試所用對象的地方。當測試方法運行結束後，不論是成功仍是失敗，都會調用另一個名叫 tearDown() 的模板方法。另外，setUpBeforeClass() 與 tearDownAfterClass() 模板方法將分別在測試用例類的第一個測試運行以前和測試用例類的最後一個測試運行以後調用。（TemplateMethodsTest.php） 用 setUp() 創建棧的基境（StackTest.php）

基境共享

在測試之間共享基境會下降測試的價值。潛在的設計問題是對象之間並 非鬆散耦合。若是解決掉潛在的設計問題並使用樁件(stub)(參見第 9 章 測試替身)來編寫測試，就能達成更好的結果，而不是在測試之間產生運行時依賴並錯過改進設計的機會。（DatabaseTest.php）

組織測試

PHPUnit 的目標之一是測試應當可組合:咱們但願能將任意數量的測試以任意組合方式運行。

未完成的測試與跳過的測試

未完成的測試

好比代碼沒寫完啊，功能測試沒寫完啊。(SampleTest.php)

方法	含義
void markTestIncomplete()	將當前測試標記爲未完成。
void markTestIncomplete(string $message)	將當前測試標記爲未完成，並用 $message 做爲說明信息。

跳過測試

(Sample1Test.php)

方法	含義
void markTestSkipped()	將當前測試標記爲已跳過。
void markTestSkipped(string $message)	將當前測試標記爲已跳過，並用 $message 做爲說明信息。

@requires 來跳過測試

數據庫測試

1. 創建基境(fixture)
2. 執行被測系統
3. 驗證結果
4. 拆除基境(fixture)

(MyApp_Tests_DatabaseTestCase1.php只作了幾個經常使用的方式，其餘的沒弄)

• Flat XML DataSet (平直 XML 數據集)
• XML DataSet (XML 數據集)
• MySQL XML DataSet (MySQL XML 數據集)
• YAML DataSet (YAML 數據集)
• CSV DataSet (CSV 數據集)
• Array DataSe (數組數據集)
• Query (SQL) DataSet (查詢(SQL)數據集)
• Database (DB) Dataset (數據庫數據集)

測試替身

Stubs (樁件) 將對象替換爲(可選地)返回配置好的返回值的測試替身的實踐方法稱爲上樁(stubbing)。能夠用樁件(stub)來「替換掉被測系統所依賴的實際組件，這樣測試就有了對被測系統的間接輸入的控制點。這使得測試能強制安排被測系統的執行路徑，不然被測系統可能沒法執行」。

模仿框架

暫時用不到，不過能夠好好研究一下。

測試實踐

在開發過程當中

在使用單元測試來確認重構的轉換步驟中確實保持原有行爲而且沒有引入錯誤時，如下狀況有助於改進項目的編碼與設計:

1. 全部單元測試均正確運行。
2. 代碼傳達其設計原則。
3. 代碼沒有冗餘。
4. 代碼所包含的類和方法的數量降至最低。

在調試過程當中

當看到缺陷報告時，你可能會有儘快修復錯誤的衝動。經驗代表，這種衝動不是好事，由於修復一個缺陷時極可能致使另一個缺陷。 下列操做能夠幫你壓住衝動:

1. 確認可以重現此缺陷。
2. 在代碼中尋找此缺陷的最小規模表達。例如，若是在輸出中有一個數字看起來不對，那麼 就尋找算出此數字的那個對象。
3. 編寫一個目前會失敗而缺陷修復後將會成功的自動測試。
4. 修復缺陷。

代碼覆蓋率分析

這個比較重要，須要xdebug的配合，在項目下面輸入相似於下面的命令便可。

vendor/bin/phpunit --coverage-text=./coverage.txt ./FileTest.php
複製代碼

備註：若是你採用了框架來作項目，感受這個干擾太大了。。。

總結

單元測試佔用開發的時候仍是不少的，大俠們儘可能寫吧，這樣就能節省qa的時間。

備註

相應的代碼位置(你照着手冊敲一遍也是能夠噠)：ttps://github.com/Birjemin/study-php

運行方式：

vendor/bin/phpunit ./phpunit/AdditionProviderTest.php
複製代碼

參考

1. 官方手冊
2. www.techug.com/post/test-c…