|
|
在這里總結的許多編程慣用法都是很值得做為單獨一個章節的，甚至一本書的。你應該把這章做為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);
}
確保你的代碼正常工作是測試的首要的目的，但是在測試你的代碼時候，你應該認識到除此之外還有一些額外的，相對次要的目的：
- 測試讓你書寫容易測試的代碼。這使得代碼松散耦合，復雜設計，而且具有很好的模塊性。
- 測試能讓你清晰的了解運行代碼的期望結果，讓你從一開始就注重于模塊的設計和分析。通過測試，也會讓你考慮所有可能的輸入和相應的輸出結果。
- 測試能很快速的了解編碼的目的。換句話說，測試事例扮演著“實例”和“文檔”的功能，準確的展示著如何構建一個類，方法等。在這本書中，我有時候通過一個測試事例來演示代碼的期望功能。通過讀取一個測試方法的聲明，你可以清楚的了解代碼是如何運行的。一個測試實例定義在代碼在明確慣用法下的運行情況。
最后，如果你的測試集――測試實例的集合――是非常徹底的，而且當所有的測試都通過的時候，你可以說你的代碼是完備的。有趣的是，這個觀點也恰好是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所寫的那樣，剛開始你可能會感到測試是很繁瑣的，但是當你為你的程序搭建好一個廣闊的測試集后，你將你的代碼更加自信！
php技術：php設計模式介紹之編程慣用法第1/3頁，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
