你是否在程序開發的過程中遇到以下的情況：當你花了很長的時間開發一個PHP應用后，你認為應該是大功告成了，可惜在調試的時候，老是不斷的發現bug，而且最可怕的是，這些bug是重復出現的，你可能發現這些bug...     

　　你是否在程序開發的過程中遇到以下的情況：當你花了很長的時間開發一個PHP應用后，你認為應該是大功告成了，可惜在調試的時候，老是不斷的發現bug，而且最可怕的是，這些bug是重復出現的，你可能發現這些bug之間會有關聯，但卻老是找不到問題的所在。

　　當你遇到以上這些令你沮喪的情況時，你一定會想能有什么更好的辦法去解決呢?辦法當然是有的!這就是使用單元測試。單元測試不但可以在一定程度上解決上述頭疼的問題，而且能讓代碼變的容易維護，還可以能讓你更多地對代碼進行重構。

　　一旦你編寫好單元測試用例，當你需要修改你的代碼時，你要做的事情就是重新運行你的單元測試用例并觀察這些單元測試用例能否通過，如果通過了的話，證明代碼是沒問題的。

　　人們往往會說：既然單元測試這么好，為什么那么多人還是不大愿意去寫單元測試呢?有以下幾種理解上的誤曲：

　　1、認為編寫單元測試太浪費時間。雖然目前很多IDE工具都為編寫單元測試建立好了框架，但還是要開發者編寫一些單元測試的代碼的。就象很多開發中的最佳實踐一樣，用正確的方法去做正確的事情會為開發節省大量的時間。每當新增加新功能時，你可能通過訪問你的網頁到處去點擊手動測試，而運行建立好的單元測試用例其速度其實比通過手工去測試的速度更快。

　　2、認為既然代碼能運行了，不需要再編寫單元測試。但假設團隊中有新的成員，如果沒有良好的單元測試用例，新成員很有可能隨意地去編碼而不考慮各種后果。如果有編寫良好的單元測試，在程序運行時進行各種測試，則能最大程度避免bug的產生。

　　3、認為編寫單元測試代碼枯燥無味。程序員的天性是解決問題，而很多程序員認為在緊張的編碼工作時，還要編寫單元測試代碼，會很枯燥。但要知道的是，如果能通過編寫單元測試在很早的階段就能盡可能發現代碼中多的錯誤的話，那么既節省時間減少了出錯，何樂而不為?

　　開始動手安裝PHPUnit

　　本文中將通過介紹PHP中的單元測試利器PHPUnit(http://phpunit.de/),并通過實際例子來講解如何在實際工作中運用PHPUnit。首先安裝PHPUnit的方法可以通過PHP下的pear去安裝：如果你想通過手動方式去安裝，可以參考PHPUnit的手冊去安裝(http://www.phpunit.de/manual/3.0/en/installation.html)。

　　編寫第一個單元測試用例

　　下面我們開始編寫第一個單元測試用例。在編寫測試用例時，要遵守如下的PHPUnit的規則：

　　1　一般地，在測試用例中，可以擴展PHPUnit_Framework_TestCase類，這樣就可以使用象setUp(),tearDown()等方法了。

　　2 測試用例的名字最好是使用約定俗成的格式，即在被測試類的后面加上”Test”,比如要測試的類為RemoteConnect,則測試用例的命名為RemoteConnectTest。

　　3 在一個測試用例中的所有的測試方法，在命名時都應該以test+測試方法名去命名，如testDoesLikeWaffles(),要注意的是該方法必須是聲明為public類型的。當然可以在你的測試用例中包含private的方法，但它們不能被phpunit所調用。

　　4 測試方法中是不能接收參數的。

　　下面首先舉個簡單的例子，代碼如下：面的代碼其實是實現連接到一個指定的服務器的功能，那么我們可以編寫測試代碼如下：在上面的代碼中，由于繼承了PHPUnit_Framework_TestCase類，因此在setUp和tearDown方法中，不需要編寫任何代碼。SetUp方法是在每個測試用例運行前進行一些初始化的工作，而tearDown則在每個測試用例運行后進行一些比如資源的釋放等工作。在測試方法中，通過使用PHPUnit的斷言assertTrue去判斷所返回的布爾值是否為真，這里是通過調用RemoteConnect.php中的connectToServe方法去判斷能否連接上服務器。

　　接下來我們運行這個單元測試，在命令行下輸入代碼：

　　phpunit /path/to/tests/RemoteConnectTest.php即可，可以看到測試順利通過的話，會輸出以下結果：可以看到，上面是通過了測試。默認情況下，PHPUnit是會運行測試用例中的所有測試方法的。下面再介紹下PHPUnit中相關的幾個斷言：

　　AssertTrue/AssertFalse 斷言是否為真值還是假

　　AssertEquals 判斷輸出是否和預期的相等

　　AssertGreaterThan 斷言結果是否大于某個值，同樣的也有LessThan(小于),GreaterThanOrEqual(大于等于)，

　　LessThanOrEqual(小于等于).

　　AssertContains 判斷輸入是否包含指定的值

　　AssertType 判斷是否屬于指定類型

　　AssertNull 判斷是否為空值

　　AssertFileExists 判斷文件是否存在

　　AssertRegExp 根據正則表達式判斷

　　舉個例子來說明下比如AssertType的使用，依然以上面的例子來說，可以用AssertType去判斷returnSampleObject返回的對象實例是否為remoteConnect，代碼如下：目前PHP框架對單元測試的支持

　　目前很多優秀的PHP框架(如Zend Framework,Symfony等)，都提供了對單元測試很好的支持。以Zend Framework為例，說明下其中是如何運行單元測試的。以上代碼其實是對Zend本身的框架進行了一個單元測試而已，可以看到，在Zend中，是通過繼承Zend_Test_PHPUnit_ControllerTestCase去對Zend的controller去進行單元測試的，可以看到，在zend中的單元測試跟PHPUnit中的差不多，但增加了另外一些新的斷言，比如上面的assertController,具體的可以參考Zend的參考手冊。

　　PHPUnit是一個輕量級的PHP測試框架。它是在PHP5下面對JUnit3系列版本的完整移植，是xUnit測試框架家族的一員(它們都基于模式先鋒Kent Beck的設計)。

　　單元測試是幾個現代敏捷開發方法的基礎，使得PHPUnit成為許多大型PHP項目的關鍵工具。這個工具也可以被Xdebug擴展用來生成代碼覆蓋率報告 ，并且可以與phing集成來自動測試，最后它還可以和Selenium整合來完成大型的自動化集成測試

　如果只有一種方式使用數據庫是正確的，您可以用很多的方式創建數據庫設計、數據庫訪問和基于數據庫的 PHP 業務邏輯代碼，但最終一般以錯誤告終。本文說明了數據庫設計和訪問數據庫的 PHP 代碼中出現的五...     　　如果只有一種方式使用數據庫是正確的，您可以用很多的方式創建數據庫設計、數據庫訪問和基于數據庫的 PHP 業務邏輯代碼，但最終一般以錯誤告終。本文說明了數據庫設計和訪問數據庫的 PHP 代碼中出現的五個常見問題，以及在遇到這些問題時如何修復它們。

　　問題 1：直接使用 MySQL

　　一個常見問題是較老的 PHP 代碼直接使用 mysql_ 函數來訪問數據庫。清單 1 展示了如何直接訪問數據庫。

　　清單 1. Access/get.php注意使用了 mysql_connect 函數來訪問數據庫。還要注意查詢，其中使用字符串連接來向查詢添加 $name 參數。

　　該技術有兩個很好的替代方案：PEAR DB 模塊和 PHP Data Objects (PDO) 類。兩者都從特定數據庫選擇提供抽象。因此，您的代碼無需太多調整就可以在 IBM® DB2®、MySQL、PostgreSQL 或者您想要連接到的任何其他數據庫上運行。

　　使用 PEAR DB 模塊和 PDO 抽象層的另一個價值在于您可以在 SQL 語句中使用 ? 操作符。這樣做可使 SQL 更加易于維護，且可使您的應用程序免受 SQL 注入攻擊。

　　使用 PEAR DB 的替代代碼如下所示。

　　清單 2. Access/get_good.php注意，所有直接用到 MySQL 的地方都消除了，只有 $dsn 中的數據庫連接字符串除外。此外，我們通過 ? 操作符在 SQL 中使用 $name 變量。然后，查詢的數據通過 query() 方法末尾的 array 被發送進來。

　　問題 2：不使用自動增量功能

　　與大多數現代數據庫一樣，MySQL 能夠在每記錄的基礎上創建自動增量惟一標識符。除此之外，我們仍然會看到這樣的代碼，即首先運行一個 SELECT 語句來找到最大的 id，然后將該 id 增 1，并找到一個新記錄。清單 3 展示了一個示例壞模式。

　　清單 3. Badid.sql這里的 id 字段被簡單地指定為整數。所以，盡管它應該是惟一的，我們還是可以添加任何值，如 CREATE 語句后面的幾個 INSERT 語句中所示。清單 4 展示了將用戶添加到這種類型的模式的 PHP 代碼。

　　清單 4. Add_user.phpadd_user.php 中的代碼首先執行一個查詢以找到 id 的最大值。然后文件以 id 值加 1 運行一個 INSERT 語句。該代碼在負載很重的服務器上會在競態條件中失敗。另外，它也效率低下。

　　那么替代方案是什么呢?使用 MySQL 中的自動增量特性來自動地為每個插入創建惟一的 ID。更新后的模式如下所示。

　　清單 5. Goodid.php我們添加了 NOT NULL 標志來指示字段必須不能為空。我們還添加了 AUTO_INCREMENT 標志來指示字段是自動增量的，添加 PRIMARY KEY 標志來指示那個字段是一個 id。這些更改加快了速度。清單 6 展示了更新后的 PHP 代碼，即將用戶插入表中。

　　清單 6. Add_user_good.php現在我不是獲得最大的 id 值，而是直接使用 INSERT 語句來插入數據，然后使用 SELECT 語句來檢索最后插入的記錄的 id。該代碼比最初的版本及其相關模式要簡單得多，且效率更高。

　　問題 3：使用多個數據庫

　　偶爾，我們會看到一個應用程序中，每個表都在一個單獨的數據庫中。在非常大的數據庫中這樣做是合理的，但是對于一般的應用程序，則不需要這種級別的分割。此外，不能跨數據庫執行關系查詢，這會影響使用關系數據庫的整體思想，更不用說跨多個數據庫管理表會更困難了。

　　那么，多個數據庫應該是什么樣的呢?首先，您需要一些數據。清單 7 展示了分成 4 個文件的這樣的數據。

　　清單 7. 數據庫文件在這些文件的多數據庫版本中，您應該將 SQL 語句加載到一個數據庫中，然后將 users SQL 語句加載到另一個數據庫中。用于在數據庫中查詢與某個特定用戶相關聯的文件的 PHP 代碼如下所示。

　　清單 8. Getfiles.phpget_user 函數連接到包含用戶表的數據庫并檢索給定用戶的 ID。get_files 函數連接到文件表并檢索與給定用戶相關聯的文件行。

　　做所有這些事情的一個更好辦法是將數據加載到一個數據庫中，然后執行查詢，比如下面的查詢。

　　清單 9. Getfiles_good.php該代碼不僅更短，而且也更容易理解和高效。我們不是執行兩個查詢，而是執行一個查詢。

　　盡管該問題聽起來有些牽強，但是在實踐中我們通常總結出所有的表應該在同一個數據庫中，除非有非常迫不得已的理由。

　　問題 4：不使用關系

　　關系數據庫不同于編程語言，它們不具有數組類型。相反，它們使用表之間的關系來創建對象之間的一到多結構，這與數組具有相同的效果。我在應用程序中看到的一個問題是，工程師試圖將數據庫當作編程語言來使用，即通過使用具有逗號分隔的標識符的文本字符串來創建數組。請看下面的模式。

　　清單 10. Bad.sql[/code]　　系統中的一個用戶可以具有多個文件。在編程語言中，應該使用數組來表示與一個用戶相關聯的文件。在本例中，程序員選擇創建一個 files 字段，其中包含一個由逗號分隔的文件 id 列表。要得到一個特定用戶的所有文件的列表，程序員必須首先從用戶表中讀取行，然后解析文件的文本，并為每個文件運行一個單獨的 SELECT 語句。該代碼如下所示。

　　清單 11. Get.php該技術很慢，難以維護，且沒有很好地利用數據庫。惟一的解決方案是重新架構模式，以將其轉換回到傳統的關系形式，如下所示。

　　清單 12. Good.sql這里，每個文件都通過 user_id 函數與文件表中的用戶相關。這可能與任何將多個文件看成數組的人的思想相反。當然，數組不引用其包含的對象 —— 事實上，反之亦然。但是在關系數據庫中，工作原理就是這樣的，并且查詢也因此要快速且簡單得多。清單 13 展示了相應的 PHP 代碼。

　　清單 13. Get_good.php這里，我們對數據庫進行一次查詢，以獲得所有的行。代碼不復雜，并且它將數據庫作為其原有的用途使用.

　　問題 5：n+1 模式

　　我真不知有多少次看到過這樣的大型應用程序，其中的代碼首先檢索一些實體(比如說客戶)，然后來回地一個一個地檢索它們，以得到每個實體的詳細信息。我們將其稱為 n+1 模式，因為查詢要執行這么多次 —— 一次查詢檢索所有實體的列表，然后對于 n 個實體中的每一個執行一次查詢。當 n=10 時這還不成其為問題，但是當 n=100 或 n=1000 時呢?然后肯定會出現低效率問題。清單 14 展示了這種模式的一個例子。

　　清單 14. Schema.sql該模式是可靠的，其中沒有任何錯誤。問題在于訪問數據庫以找到一個給定作者的所有書籍的代碼中，如下所示。

　　清單 15. Get.php如果您看看下面的代碼，您可能會想，“嘿，這才是真正的清楚明了。” 首先，得到作者 id，然后得到書籍列表，然后得到有關每本書的信息。的確，它很清楚明了，但是其高效嗎?回答是否定的。看看只是檢索 Jack Herrington 的書籍時要執行多少次查詢。一次獲得 id，另一次獲得書籍列表，然后每本書執行一次查詢。三本書要執行五次查詢!

　　解決方案是用一個函數來執行大量的查詢，如下所示。

　　清單 16. Get_good.php[/code]　　現在檢索列表需要一個快速、單個的查詢。這意味著我將很可能必須具有幾個這些類型的具有不同參數的方法，但是實在是沒有選擇。如果您想要具有一個擴展的 PHP 應用程序，那么必須有效地使用數據庫，這意味著更智能的查詢。

　　本例的問題是它有點太清晰了。通常來說，這些類型的 n+1 或 n*n 問題要微妙得多。并且它們只有在數據庫管理員在系統具有性能問題時在系統上運行查詢剖析器時才會出現。

　　結束語

　　數據庫是強大的工具，就跟所有強大的工具一樣，如果您不知道如何正確地使用就會濫用它們。識別和解決這些問題的訣竅是更好地理解底層技術。長期以來，我老聽到業務邏輯編寫人員抱怨，他們不想要必須理解數據庫或 SQL 代碼。他們把數據庫當成對象使用，并疑惑性能為什么如此之差。

　　他們沒有認識到，理解 SQL 對于將數據庫從一個困難的必需品轉換成強大的聯盟是多么重要。如果您每天使用數據庫，但是不熟悉 SQL，那么請閱讀 The Art of SQL，這本書寫得很好，實踐性也很強，可以指導您基本了解數據庫。

關鍵詞：測試利器