php設計模式介紹之編程慣用法第1/3頁

在這裡總結的許多編程慣用法都是很值得做為單獨一個章節的，甚至一本書的。你應該把這章做為PHP模式設計使用慣用法的相關介紹，而且查看一些列出的參考書來進行更深入的學習。

測試你的代碼

可能沒有什麼代碼慣用法比測試代碼更加重要了。好的測試可以提高開發速度。

可能一開始，這句格言會和你的直覺相矛盾。你可能會斷言，測試是自由的障礙物。事實上恰恰相反，如果你十分完整的運行那些測試來檢查你的軟體的公用介面，你就可能在不改變（或者更加糟糕，破壞）原來的應用軟體的前提下改變自己系統內在的執行。測試並檢驗你的公用介面的精確性和正確性，並且讓自己隨意改變一些代碼的內在工作來確保你的軟體是正確而且沒有bug（錯誤）。

在討論更多關於測試的好處之前，先讓我們看一個樣本。這本書裡面所有的測試執行個體都使用了PHP測試架構——SimpleTest 。這個測試架構可以在 http://simpletest.org 擷取到。

考慮下面的代碼

<?php
// PHP4
// the subject code
define(‘TAX_RATE', 0.07);
function calculate_sales_tax($amount) {
round($amount * TAX_RATE,2);
}
// include test library
require_once ‘simpletest/unit_tester.php';
require_once ‘simpletest/reporter.php';
// the test
class TestingTestCase extends UnitTestCase {
function TestingTestCase($name='') {
$this->UnitTestCase($name);
}
function TestSalesTax() {
$this->assertEqual(7, calculate_sales_tax(100));
}
}
// run the test
$test = new TestingTestCase(‘Testing Unit Test');
$test->run(new HtmlReporter());

上面的代碼首先定義了一個常量——TAX_RATE，和一個計算銷售稅的函數。接著，程式碼封裝含了使用SimpleTest架構的必備組件：單體測試本身和一個用來顯示測試結果的“reporter”模組。

類TestingTestCase繼承於SimpleTest架構的UnitTestCase類。通過擴充UnitTestCase，類TestingTestCase裡面所有使用Test開頭的方法都將被認為是測試執行個體——創造條件來調試你的代碼並斷言結果。

TestingTestCase定義了一個測試，TestSalesTax()，它包含了一個斷言函數AssertEqual()。如果它的前兩個輸入參數是相等的，它將返回true，否則返回false。（如果你想顯示assertEqual()失敗的資訊，你可以傳入三個參數就像這樣$this->assertEqual(7,calculate_sales_tax(100), “The sales tax calculation failed”)）。

代碼的最後兩行建立了這個測試執行個體的實體並且使用一個HtmlReporter運行了它。你可以訪問這個web頁面來運行這個簡單的測試。

運行這個測試將顯示測試名稱，失敗斷言的詳細情況和一個總結條。（綠色的意味著成功（所有的斷言都通過了），而紅色的暗示著失敗（至少有一個斷言沒有通過））

（assertion(斷言)在軟體開發中是一種常用的調試方式，很多開發語言中都支援這種機制。在實現中，assertion就是在程式中的一條語句，它對一個boolean運算式進行檢查，一個正確程式必須保證這個boolean運算式的值為true；如果該值為false，說明程式已經處於不正確的狀態下，系統將給出警告或退出。一般來說，assertion用於保證程式最基本、關鍵的正確性。assertion檢查通常在開發與測試時開啟。為了提高效能，在軟體發布後，assertion檢查通常是關閉的。）

註：（assertion(斷言)在軟體開發中是一種常用的調試方式，很多開發語言中都支援這種機制。在實現中，assertion就是在程式中的一條語句，它對一個boolean運算式進行檢查，一個正確程式必須保證這個boolean運算式的值為true；如果該值為false，說明程式已經處於不正確的狀態下，系統將給出警告或退出。一般來說，assertion用於保證程式最基本、關鍵的正確性。assertion檢查通常在開發與測試時開啟。為了提高效能，在軟體發布後，assertion檢查通常是關閉的。）

上面的代碼有一個（有意的）錯誤，所以運行是不能通過了，顯示結果如下：

Calculate_sales_tax()這麼一個簡單的才一行的函數哪裡出錯了呢？你可能已經注意到這個函數沒有返回結果。下面是正確的函數：

function calculate_sales_tax($amount) {
return round($amount * TAX_RATE,2);
}

修改後運行，測試通過。

但是一個簡單的測試並不能保證代碼是穩定的。比如，你把calculate_sales_tax()改成 function calculate_sales_tax($amount) { return 7; }，代碼也會通過測試，但只有當1美元等價於100的時候才是正確的。你可以自己增加一些額外的測試方法來測試其他的靜態值。

function TestSomeMoreSalesTax() {
$this->assertEqual(3.5, calculate_sales_tax(50));
}

或者改變函數TestSalesTax()來驗證第二個（和第三個，等等）值，如下所示

function TestSalesTax() {
$this->assertEqual(7, calculate_sales_tax(100));
$this->assertEqual(3.5, calculate_sales_tax(50));
}

到目前為止還有一種更好的方法，就是新增加一個測試：選擇隨即值來測試你的代碼。具體如下：

function TestRandomValuesSalesTax() {
$amount = rand(500,1000);
$this->assertTrue(defined(‘TAX_RATE'));
$tax = round($amount*TAX_RATE*100)/100;
$this->assertEqual($tax, calculate_sales_tax($amount));
}

TestRandomValuesSalesTax()引入了方法assertTrue()，如果傳入的第一個變數等于于布爾真則assertTrue()通過。（和方法assertEqual()一樣，方法assertTrue()在接受一個可選擇性的、額外的後將返回一個失敗的資訊）。所以TestRandomValuesSalesTax()首先認為常量TAX_RATE已經定義了，然後使用這個常量來計算隨機播放的的數量的稅收。

但是TestRandomValuesSalesTax()也存在一個問題：它很大程度的依賴於方法calculate_sales_tax()。測試是應該和特殊的實現細節無關的。一個更好的測試應該只建立一個合理的分界線。接下來的這個測試假定銷售稅永遠不會超過20％。

function TestRandomValuesSalesTax() {
$amount = rand(500,1000);
$this->assertTrue(calculate_sales_tax($amount)<$amount*0.20);
}

確保你的代碼正常工作是測試的首要的目的，但是在測試你的代碼時候，你應該認識到除此之外還有一些額外的，相對次要的目的：

1. 測試讓你書寫容易測試的代碼。這使得代碼鬆散耦合，複雜設計，而且具有很好的模組性。
2. 測試能讓你清晰的瞭解運行代碼的期望結果，讓你從一開始就注重於模組的設計和分析。通過測試，也會讓你考慮所有可能的輸入和相應的輸出結果。
3. 測試能很快速的瞭解編碼的目的。換句話說，測試案例扮演著“執行個體”和“文檔”的功能，準確的展示著如何構建一個類，方法等。在這本書中，我有時候通過一個測試案例來示範代碼的期望功能。通過讀取一個測試方法的聲明，你可以清楚的瞭解代碼是如何啟動並執行。一個測試執行個體定義在代碼在明確慣用法下的運行情況。

最後，如果你的測試集——測試執行個體的集合——是非常徹底的，而且當所有的測試都通過的時候，你可以說你的代碼是完備的。有趣的是，這個觀點也恰好是Test Driven Development（測試驅動開發）的特徵之一。

Test Driven Development（TDD）也被認為是Test First Coding（編碼前測試）。Test First Coding是一種把測試更提前一步的方法：在你寫任何代碼之前先寫好測試。你可以從http://xprogramming.com/xpmag/testFirstGuidelines.htm下載到一份很好的，簡潔的關於TDD的摘要文章，同時下載到一本很好的關於策略的入門書——Kent Beck著作的《Test Driven Development：By Example》(這本書的例子都是用JAVA開發的，但其中代碼的可讀性是很好的，而且對主題的介紹和說明都做的很好的)。

註：敏捷開發（Agile Development）
最近，單體測試——特別是測繪驅動開發——已經和敏捷開發方法學緊密的聯絡起來了，比如說極限編程(XP)。極限編程的焦點關注於快速的反覆的發步功能性的代碼給客戶，並把變化的客戶需求做為開發過程中的必備部分。下面是一些關於學習敏捷編程的線上資源：
函數性測試
這本書裡面的大部分測試例子都是用來測試面對對象的代碼，但是所有形式的編程都可以從中得到收穫的。單體測試架構，比如說PHPUnits和SimpleTest，也都能很容易的用來測試功能函數的。例如上面的SimpleTest例子，它就是用來測試calculate_sales_tax()函數的。世界各地的程式員們：把單體測試案例放到你的函數庫裡面吧！

我希望經過上面的討論後，你也會被帶動起來——“測試引導”(Test Infected)！（這個術語，原創於Erich Gamma，詳細情況請見文章http://junit.sourceforge.net/doc/testinfected/testing.htm），就象Gamma所寫的那樣，剛開始你可能會感到測試是很繁瑣的，但是當你為你的程式搭建好一個廣闊的測試集後，你將你的代碼更加自信！