寫PHP代碼你搞過單元測試嗎

其實一開始我內(nèi)心是想做單元測試(unit testing)的，但時間久了，也就不想了。

要想通過PHP編程成為技術(shù)領(lǐng)域的專家，其實功夫在PHP之外。數(shù)據(jù)庫至少得看幾本書，xml至少得看一本書，單元測試至少得看一本書，軟件工程至少看一本，數(shù)據(jù)結(jié)構(gòu)與算法至少看一本，*nix至少得看一本，Web服務(wù)器至少看一本，佛經(jīng)得看一本，道德經(jīng)得看一本，易經(jīng)可能也得看一本，等等，不停的看下去。

概念

要寫單元測試，必須要有一些基本概念。這些概念PHP是不會教給你的。

我們先從百度百科中吸取一點營養(yǎng)。

工廠在組裝一臺電視機之前，會對每個元件都進行測試，這就是單元測試。

單元測試，是指對軟件中的最小可測試單元進行檢查和驗證。對于單元測試中單元的含義，一般來說，要根據(jù)實際情況去判定其具體含義，如C語言中單元指一個函數(shù)，Java里單元指一個類，圖形化的軟件中可以指一個窗口或一個菜單等。總的來說，單元就是人為規(guī)定的最小的被測功能模塊。單元測試是在軟件開發(fā)過程中要進行的最低級別的測試活動，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試。

單元測試是由程序員自己來完成，最終受益的也是程序員自己。程序員有責(zé)任編寫功能代碼，同時也就有責(zé)任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。

--百度百科

安裝

PHPUnit目前穩(wěn)定版已到了4.6，網(wǎng)上很多的姿勢都已失效。比如，發(fā)行方式，以前都是用Pear進行安裝，現(xiàn)在呢，直接是Phar包或者Composer的方式依賴安裝。

<code>wget https://phar.phpunit.de/phpunit.phar? chmod +x phpunit.phar? sudo mv phpunit.phar /usr/local/bin/phpunit? phpunit --version</code>

<code>{    "require-dev": {        "phpunit/phpunit": "4.6.*"    }}</code>

但另一個對初學(xué)者很關(guān)鍵的東東phpunit-skelgen就沒有包含在這個包里，而且很難找到下載地址：https://phar.phpunit.de/phpunit-skelgen.phar

<code>wget https://phar.phpunit.de/phpunit-skelgen.pharchmod +x phpunit-skelgen.pharmv phpunit-skelgen.phar /usr/local/bin/phpunit-skelgen</code>

解決的問題

在開發(fā)過程中，當(dāng)需要對軟件的內(nèi)部結(jié)構(gòu)進行更改時，你實際上是要在不影響其可見行為的情況下讓它更加容易理解、更加易于修改，測試套件對于安全地進行這些所謂的重構(gòu)而言是非常寶貴的。否則，你可能在重組過程中將系統(tǒng)搞壞而不自知。

在使用單元測試來確認重構(gòu)的轉(zhuǎn)換步驟中確實保持原有行為并且沒有引入錯誤時，以下情況有助于改進項目的編碼與設(shè)計：

• 所有單元測試均正確運行。

• 代碼傳達其設(shè)計原則。

• 代碼沒有冗余。

• 代碼所包含的類和方法的數(shù)量降至最低。

當(dāng)需要向系統(tǒng)內(nèi)添加新的功能時，首先為其編寫測試。然后，當(dāng)測試能夠正常運行就標(biāo)志著開發(fā)完成了。

優(yōu)點

1、它是一種驗證行為。

程序中的每一項功能都是測試來驗證它的正確性。它為以后的開發(fā)提供支援。就算是開發(fā)后期，我們也可以輕松的增加功能或更改程序結(jié)構(gòu)，而不用擔(dān)心這個過程中會破壞重要的東西。而且它為代碼的重構(gòu)提供了保障。這樣，我們就可以更自由的對程序進行改進。

2、它是一種設(shè)計行為。

編寫單元測試將使我們從調(diào)用者觀察、思考。特別是先寫測試（test-first），迫使我們把程序設(shè)計成易于調(diào)用和可測試的，即迫使我們解除軟件中的耦合。

3、它是一種編寫文檔的行為。

單元測試是一種無價的文檔，它是展示函數(shù)或類如何使用的最佳文檔。這份文檔是可編譯、可運行的，并且它保持最新，永遠與代碼同步。

4、它具有回歸性。

自動化的單元測試避免了代碼出現(xiàn)回歸，編寫完成之后，可以隨時隨地的快速運行測試。

實踐

什么時候測試？

單元測試越早越好，早到什么程度？

極限編程(Extreme Programming,或簡稱XP)講究TDD，即測試驅(qū)動開發(fā)，先編寫測試代碼，再進行開發(fā)。在實際的工作中，可以不必過分強調(diào)先什么后什么，重要的是高效和感覺舒適。

從經(jīng)驗來看，先編寫產(chǎn)品函數(shù)的框架，然后編寫測試函數(shù)，針對產(chǎn)品函數(shù)的功能編寫測試用例，然后編寫產(chǎn)品函數(shù)的代碼，每寫一個功能點都運行測試，隨時補充測試用例。

所謂先編寫產(chǎn)品函數(shù)的框架，是指先編寫函數(shù)空的實現(xiàn)，有返回值的直接返回一個合適值，編譯通過后再編寫測試代碼，這時，函數(shù)名、參數(shù)表、返回類型都應(yīng)該確定下來了，所編寫的測試代碼以后需修改的可能性比較小。

由誰測試？

單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應(yīng)該由程序員完成，也就是說，經(jīng)過了單元測試的代碼才是已完成的代碼，提交產(chǎn)品代碼時也要同時提交測試代碼。測試部門可以作一定程度的審核。

請一定要看完官方文檔：。

要進行充分的單元測試，一般來說應(yīng)專門編寫測試代碼，并與產(chǎn)品代碼隔離。但對于初學(xué)者來說，總是會有點別扭，因為感覺額外做了很多工作，影響開發(fā)效率。其實像phpunit也是支持在類方法的文檔注釋塊(docblock)中使用 @test 標(biāo)注將其標(biāo)記為測試方法的。這樣，徹底貫徹我們代碼即文檔的思想。

<code><?phpclass Calculator{    /**     * @assert (0, 0) == 0     * @assert (0, 1) == 1     * @assert (1, 0) == 1     * @assert (1, 1) == 2     * @assert (1, 2) == 4     */    public function add($a, $b)    {        return $a + $b;    }}</code>

現(xiàn)實難題

我們到底要測什么？算法？一般很少。

大都是在編寫業(yè)務(wù)功能。而且大多數(shù)是基于數(shù)據(jù)庫的系統(tǒng)開發(fā)。這是我們實施PHP單元測試最大的難點所在。需要整合PHPUnit的DBUnit測試，也就是一開始就得學(xué)習(xí)DBUnit的知識。

在各種編程語言中，許多入門與中級的單元測試范例都暗示著這樣一種信息：很容易用簡單的測試來對應(yīng)用程序的邏輯進行測試。但是對于以數(shù)據(jù)庫為中心的應(yīng)用程序而言，這與現(xiàn)實相去甚遠。一旦開始使用諸如 Wordpress、TYPO3、或 Symfony（配合 Doctrine 或 Propel）之類的東西，就很容易在用 PHPUnit 時碰到超多問題：正是由于這些庫和數(shù)據(jù)庫之間實在耦合的太緊密了。

你大概會在日常工作面對的項目中經(jīng)歷這一幕。你打算把你那或生疏或純熟的 PHPUnit 技能用到工作中去，結(jié)果被以下問題之一卡住了：

• 待測方法執(zhí)行了一個相當(dāng)大的 JOIN 操作，并且得到的數(shù)據(jù)用于計算某些重要的結(jié)果。
  
• 業(yè)務(wù)邏輯中混合執(zhí)行了 SELECT、INSERT、UPDATE 和 DELETE 語句。
  
• 為了給待測方法建立合理的初始數(shù)據(jù)，需要在兩個以上（可能遠超過）表里設(shè)置測試數(shù)據(jù)。

DbUnit

DbUnit擴展大大簡化了為測試設(shè)置數(shù)據(jù)庫的操作，并且可以在對數(shù)據(jù)執(zhí)行了一系列操作之后驗證數(shù)據(jù)庫的內(nèi)容。

DbUnit所支持的供應(yīng)商

DbUnit 目前支持 MySQL、PostgreSQL、Oracle 和 SQLite。通過集成 Zend Framework 或 Doctrine 2，也可以訪問其他數(shù)據(jù)庫系統(tǒng)，比如 IBM DB2 或者 Microsoft SQL Server。

數(shù)據(jù)庫測試的難點

為什么所有單元測試的范例都不包含數(shù)據(jù)庫交互？這里有個很好的理由：這類測試的建立和維護都很復(fù)雜。對數(shù)據(jù)庫進行測試時，需要考慮以下這些變數(shù)：

• 數(shù)據(jù)庫和表
  
• 向表中插入測試所需要的行
  
• 測試運行完畢后驗證數(shù)據(jù)庫的狀態(tài)
  
• 每個新測試都要清理數(shù)據(jù)庫

許多數(shù)據(jù)庫 API，比如 PDO、MySQLi 或者 OCI8，都十分繁瑣且書寫起來十分冗長，因此，手工進行這些步驟絕對是噩夢。

測試代碼應(yīng)當(dāng)盡可能簡短精確，這有若干原因：

• 你不希望因為生產(chǎn)代碼的小變更而需要對測試代碼進行數(shù)量可觀的修改。

• 你希望在哪怕好幾個月以后也能輕松地閱讀并理解測試代碼。

另外，必須認識到，對于代碼而言，本質(zhì)上來說數(shù)據(jù)庫是全局輸入變量。測試套件中的兩個不同的測試可能是運行在同一個數(shù)據(jù)庫上的，并且可能把數(shù)據(jù)重用好多次。一個測試中出現(xiàn)的失敗很容易影響到后繼測試的結(jié)果，從而讓整個測試過程變得非常艱難。前面提到的清理步驟對于解決“數(shù)據(jù)庫是全局輸入”的問題是非常重要的。

DbUnit 以一種優(yōu)雅的方式來幫助簡化數(shù)據(jù)庫測試中的所有這些問題。

PHPUnit 無法幫你解決的問題是，相對于不使用數(shù)據(jù)的測試而言，數(shù)據(jù)庫測試是非常慢的。隨著數(shù)據(jù)庫交互規(guī)模的增大，運行測試可能需要耗費可觀的時間。然而，只要保持每個測試所使用的數(shù)據(jù)量較小并且盡可能用非數(shù)據(jù)庫測試來對代碼進行測試，即使很大的測試套件也能輕松在一分鐘內(nèi)跑完。

數(shù)據(jù)庫測試的四個階段

Gerard Meszaros 在他的書《xUnit 測試模式》中列出了單元測試的四個階段：

• 建立基架(fixture)
  
• 執(zhí)行被測系統(tǒng)
  
• 驗證結(jié)果
  
• 拆除基架(fixture)

什么是基架(fixture)？

<code>基架(fixture)是對開始執(zhí)行某個測試時應(yīng)用程序和數(shù)據(jù)庫所處初始狀態(tài)的描述。</code>

對數(shù)據(jù)庫進行測試至少要處理建立與拆除的步驟，在其中完成清理工作，并將所需的基架數(shù)據(jù)寫入表內(nèi)。然而對于數(shù)據(jù)庫擴展模塊而言，在數(shù)據(jù)庫測試中有很好的理由將這四個步驟還原成類似下面這樣的工作流程，這個流程對于每個測試都會完整執(zhí)行：

1. 清理數(shù)據(jù)庫

由于總是會有某個測試運行在并不確定表中是否有數(shù)據(jù)的數(shù)據(jù)庫上，PHPUnit 在所有指定表上執(zhí)行 TRUNCATE 操作來把它們清空。

1. 建立基架

PHPUnit 隨后將迭代所有指定的基架數(shù)據(jù)行并將其插入到對應(yīng)的表里。

3–5. 運行測試、驗證結(jié)果、并拆除基架

在所有數(shù)據(jù)庫都完成重置并加載好初始狀態(tài)后，PHPUnit 才會執(zhí)行實際的測試。這個部分的測試代碼完全不需要數(shù)據(jù)庫擴展模塊的參與，可以隨意測試任何想要測試的內(nèi)容。

在測試中，驗證的目的可以使用一個名為 assertDataSetsEqual() 的特殊斷言來實現(xiàn)。當(dāng)然，這完全是可選的。

一些術(shù)語

• 單元測試
  
• 集成測試
  
• 回歸測試
  
• 測試用例
  
• 斷言
  
• 基架Fixture