推薦：《PHP設計模式介紹》導言
當你在不斷的試圖從你的應用程序中發(fā)現(xiàn)新的特征時，你是否發(fā)現(xiàn)你提出的解決方法和一些以前你已經(jīng)實現(xiàn)的東西是如此的類似呢？如果你是一個程序員（即使你才 開始很短的時間），你都可能回答&ldqu

學習一門新的語言意味著要采用新的慣用法。這章將介紹或者可能重新強調(diào)一些慣用法。你會發(fā)現(xiàn)這些慣用法在你要在代碼中實現(xiàn)設計模式時候是非常有用的。

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

測試你的代碼

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

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

在討論更多關于測試的好處之前，先讓我們看一個示例。這本書里面所有的測試實例都使用了PHP測試框架——SimpleTest 。這個測試框架可以在 http://simpletest.org 獲取到。

考慮下面的代碼

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

類TestingTestCase繼承于SimpleTest框架的UnitTestCase類。通過擴展UnitTestCase，類TestingTestCase里面所有使用Test開頭的方法都將被認為是測試實例——創(chuàng)造條件來調(diào)試你的代碼并斷言結果。

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

代碼的最后兩行創(chuàng)建了這個測試實例的實體并且使用一個HtmlReporter運行了它。你可以訪問這個web頁面來運行這個簡單的測試。

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

（assertion(斷言)在軟件開發(fā)中是一種常用的調(diào)試方式，很多開發(fā)語言中都支持這種機制。在實現(xiàn)中，assertion就是在程序中的一條語句，它對一個boolean表達式進行檢查，一個正確程序必須保證這個boolean表達式的值為true；如果該值為false，說明程序已經(jīng)處于不正確的狀態(tài)下，系統(tǒng)將給出警告或退出。一般來說，assertion用于保證程序最基本、關鍵的正確性。assertion檢查通常在開發(fā)和測試時開啟。為了提高性能，在軟件發(fā)布后，assertion檢查通常是關閉的。）

注：（assertion(斷言)在軟件開發(fā)中是一種常用的調(diào)試方式，很多開發(fā)語言中都支持這種機制。在實現(xiàn)中，assertion就是在程序中的一條語句，它對一個boolean表達式進行檢查，一個正確程序必須保證這個boolean表達式的值為true；如果該值為false，說明程序已經(jīng)處于不正確的狀態(tài)下，系統(tǒng)將給出警告或退出。一般來說，assertion用于保證程序最基本、關鍵的正確性。assertion檢查通常在開發(fā)和測試時開啟。為了提高性能，在軟件發(fā)布后，assertion檢查通常是關閉的。）

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

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

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

修改后運行，測試通過。

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

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

或者改變函數(shù)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已經(jīng)定義了，然后使用這個常量來計算隨機選擇的的數(shù)量的稅收。

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

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

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

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

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

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開發(fā)的，但其中代碼的可讀性是很好的，而且對主題的介紹和說明都做的很好的)。

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

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

分享：php escapeshellcmd多字節(jié)編碼漏洞
漏洞公告在http://www.sektioneins.de/advisories/SE-2008-03.txt PHP 5 = 5.2.5 PHP 4 = 4.4.8 一些允許如GBK，EUC-KR, SJIS等寬字節(jié)字符集的系統(tǒng)都可能受此影響，影響還是非常