測試驅動的開發和單元測試是確保代碼在經過修改和重大調整之后依然能如我們期望的一樣工作的最新方法。在本文中，您將學習到如何在模塊、數據庫和用戶界面(UI)層對自己的 PHP 代碼進行單元測試。

現在是凌晨 3 點。我們怎樣才能知道自己的代碼依然在工作呢?

Web 應用程序是 24x7 不間斷運行的，因此我的程序是否還在運行這個問題會在晚上一直困擾我。單元測試已經幫我對自己的代碼建立了足夠的信心 —— 這樣我就可以安穩地睡個好覺了。

單元測試 是一個為代碼編寫測試用例并自動運行這些測試的框架。測試驅動的開發是一種單元測試方法，其思想是應該首先編寫測試程序，并驗證這些測試可以發現錯誤，然后才開始編寫需要通過這些測試的代碼。當所有測試都通過時，我們開發的特性也就完成了。這些單元測試的價值是我們可以隨時運行它們 —— 在簽入代碼之前，重大修改之后，或者部署到正在運行的系統之后都可以。

PHP 單元測試

對于 PHP 來說，單元測試框架是 PHPUnit2。可以使用 PEAR 命令行作為一個 PEAR 模塊來安裝這個系統：% pear install PHPUnit2。

在安裝這個框架之后，可以通過創建派生于 PHPUnit2_Framework_TestCase 的測試類來編寫單元測試。

模塊單元測試

我發現開始單元測試最好的地方是在應用程序的業務邏輯模塊中。我使用了一個簡單的例子：這是一個對兩個數字進行求和的函數。為了開始測試，我們首先編寫測試用例，如下所示。

清單 1. TestAdd.php

<?phprequire_once 'Add.php';require_once 'PHPUnit2/Framework/TestCase.php';class TestAdd extends PHPUnit2_Framework_TestCase{; function test1() { $this->assertTrue( add( 1, 2 ) == 3 ); }; function test2() { $this->assertTrue( add( 1, 1 ) == 2 ); }}?>

這個 TestAdd 類有兩個方法，都使用了 test 前綴。每個方法都定義了一個測試，這個測試可以與清單 1 一樣簡單，也可以十分復雜。在本例中，我們在第一個測試中只是簡單地斷定 1 加 2 等于 3，在第二個測試中是 1 加 1 等于 2。

PHPUnit2 系統定義了 assertTrue() 方法，它用來測試參數中包含的條件值是否為真。然后，我們又編寫了 Add.php 模塊，最初讓它產生錯誤的結果。

清單 2. Add.php

<?phpfunction add( $a, $b ) { return 0; }?>

現在運行單元測試時，這兩個測試都會失敗。

清單 3. 測試失敗

% phpunit TestAdd.phpPHPUnit 2.2.1 by Sebastian Bergmann.FFTime: 0.0031270980834961There were 2 failures:1) test1(TestAdd)2) test2(TestAdd)FAILURES!!!Tests run: 2, Failures: 2, Errors: 0, Incomplete Tests: 0.

現在我知道這兩個測試都可以正常工作了。因此，可以修改 add() 函數來真正地做實際的事情了。

現在這兩個測試都可以通過了。

<?phpfunction add( $a, $b ) { return $a+$b; }?>

清單 4. 測試通過

% phpunit TestAdd.phpPHPUnit 2.2.1 by Sebastian Bergmann...Time: 0.0023679733276367OK (2 tests)%

盡管這個測試驅動開發的例子非常簡單，但是我們可以從中體會到它的思想。我們首先創建了測試用例，并且有足夠多的代碼讓這個測試運行起來，不過結果是錯誤的。然后我們驗證測試的確是失敗的，接著實現了實際的代碼使這個測試能夠通過。

我發現在實現代碼時我會一直不斷地添加代碼，直到擁有一個覆蓋所有代碼路徑的完整測試為止。在本文的最后，您會看到有關編寫什么測試和如何編寫這些測試的一些建議。

數據庫測試

在進行模塊測試之后，就可以進行數據庫訪問測試了。數據庫訪問測試帶來了兩個有趣的問題。首先，我們必須在每次測試之前將數據庫恢復到某個已知點。其次，要注意這種恢復可能會對現有數據庫造成破壞，因此我們必須對非生產數據庫進行測試，或者在編寫測試用例時注意不能影響現有數據庫的內容。

數據庫的單元測試是從數據庫開始的。為了闡述這個問題，我們需要使用下面的簡單模式。

清單 5. Schema.sql

DROP TABLE IF EXISTS authors;CREATE TABLE authors (; id MEDIUMINT NOT NULL AUTO_INCREMENT,; name TEXT NOT NULL,; PRIMARY KEY ( id ));

清單 5 是一個 authors 表，每條記錄都有一個相關的 ID。

接下來，就可以編寫測試用例了。

清單 6. TestAuthors.php

<?phprequire_once 'dblib.php';require_once 'PHPUnit2/Framework/TestCase.php';class TestAuthors extends PHPUnit2_Framework_TestCase{; function test_delete_all() {;;$this->assertTrue( Authors::delete_all() )}; function test_insert() {;;$this->assertTrue( Authors::delete_all() );;;$this->assertTrue( Authors::insert( 'Jack' ) )}; function test_insert_and_get() {;;$this->assertTrue( Authors::delete_all() );;;$this->assertTrue( Authors::insert( 'Jack' ) );;;$this->assertTrue( Authors::insert( 'Joe' ) );;;$found = Authors::get_all();;;$this->assertTrue( $found != null );;;$this->assertTrue( count( $found ) == 2 )}}?>

這組測試覆蓋了從表中刪除作者、向表中插入作者以及在驗證作者是否存在的同時插入作者等功能。這是一個累加的測試，我發現對于尋找錯誤來說這非常有用。觀察一下哪些測試可以正常工作，而哪些測試不能正常工作，就可以快速地找出哪些地方出錯了，然后就可以進一步理解它們之間的區別。

最初產生失敗的 dblib.php PHP 數據庫訪問代碼版本如下所示。

清單 7. dblib.php

<?phprequire_once('DB.php');class Authors{; public static function get_db(); {;$dsn = 'mysql://root:password@localhost/unitdb';;$db =& DB::Connect( $dsn, array() );;if (PEAR::isError($db)) { die($db->getMessage()); };return $db}; public static function delete_all(); {;return false}; public static function insert( $name ); {;return false}; public static function get_all(); {;return null}}?>

對清單 8 中的代碼執行單元測試會顯示這 3 個測試全部失敗了：

清單 8. dblib.php

% phpunit TestAuthors.phpPHPUnit 2.2.1 by Sebastian Bergmann.FFFTime: 0.007500171661377There were 3 failures:1) test_delete_all(TestAuthors)2) test_insert(TestAuthors)3) test_insert_and_get(TestAuthors)FAILURES!!!Tests run: 3, Failures: 3, Errors: 0, Incomplete Tests: 0.%

現在我們可以開始添加正確訪問數據庫的代碼 —— 一個方法一個方法地添加 —— 直到所有這 3 個測試都可以通過。最終版本的 dblib.php 代碼如下所示。

清單 9. 完整的 dblib.php

<?phprequire_once('DB.php');class Authors{; public static function get_db(); {;$dsn = 'mysql://root:password@localhost/unitdb';;$db =& DB::Connect( $dsn, array() );;if (PEAR::isError($db)) { die($db->getMessage()); };return $db}; public static function delete_all(); {;$db = Authors::get_db();;$sth = $db->prepare( 'DELETE FROM authors' );;$db->execute( $sth );;return true}; public static function insert( $name ); {;$db = Authors::get_db();;$sth = $db->prepare( 'INSERT INTO authors VALUES (null,?)' );;$db->execute( $sth, array( $name ) );;return true}; public static function get_all(); {;$db = Authors::get_db();;$res = $db->query( 'SELECT * FROM authors' );;$rows = array();;while( $res->fetchInto( $row ) ) { $rows []= $row; };return $rows}}?>

HTML 測試

對整個 PHP 應用程序進行測試的下一個步驟是對前端的超文本標記語言(HTML)界面進行測試。要進行這種測試，我們需要一個如下所示的 Web 頁面。

清單 10. TestPage.php

<?phprequire_once 'HTTP/Client.php';require_once 'PHPUnit2/Framework/TestCase.php';class TestPage extends PHPUnit2_Framework_TestCase{; function get_page( $url ); {;$client = new HTTP_Client();;$client->get( $url );;$resp = $client->currentResponse();;return $resp['body']}; function test_get(); {;$page = TestPage::get_page( 'http://localhost/unit/add.php' );;$this->assertTrue( strlen( $page ) > 0 );;$this->assertTrue( preg_match( '/<html>/', $page ) == 1 )}; function test_add(); {;$page = TestPage::get_page( 'http://localhost/unit/add.php?a=10&b=20' );;$this->assertTrue( strlen( $page ) > 0 );;$this->assertTrue( preg_match( '/<html>/', $page ) == 1 );;preg_match( '/<span id='result'>(.*?)</span>/', $page, $out );;$this->assertTrue( $out[1]=='30' )}}?>

這個測試使用了 PEAR 提供的 HTTP Client 模塊。我發現它比內嵌的 PHP Client URL Library(CURL)更簡單一點兒，不過也可以使用后者。

有一個測試會檢查所返回的頁面，并判斷這個頁面是否包含 HTML。第二個測試會通過將值放到請求的 URL 中來請求計算 10 和 20 的和，然后檢查返回的頁面中的結果。

這個頁面的代碼如下所示。

清單 11. TestPage.php

<html><body><form><input type='text' name='a' value='<?php echo($_REQUEST['a']); ?>' /> +<input type='text' name='b' value='<?php echo($_REQUEST['b']); ?>' /> =<span id='result'><?php echo($_REQUEST['a']+$_REQUEST['b']); ?></span><br/><input type='submit' value='Add' /></form></body></html>

這個頁面相當簡單。兩個輸入域顯示了請求中提供的當前值。結果 span 顯示了這兩個值的和。 標記標出了所有區別：它對于用戶來說是不可見的，但是對于單元測試來說卻是可見的。因此單元測試并不需要復雜的邏輯來找到這個值。相反，它會檢索一個特定 標記的值。這樣當界面發生變化時，只要 span 存在，測試就可以通過。

與前面一樣，首先編寫測試用例，然后創建一個失敗版本的頁面。我們對失敗情況進行測試，然后修改頁面的內容使其可以工作。結果如下：

清單 12. 測試失敗情況，然后修改頁面

% phpunit TestPage.phpPHPUnit 2.2.1 by Sebastian Bergmann...Time: 0.25711488723755OK (2 tests)%

這兩個測試都可以通過，這就意味著測試代碼可以正常工作。

在對這段代碼運行測試時，所有的測試都可以沒有問題地運行，這樣我們就可以知道自己的代碼可以正確工作了。

不過對 HTML 前端的測試有一個缺陷：JavaScript。超文本傳輸協議(HTTP)客戶機代碼對頁面進行檢索，但是卻沒有執行 JavaScript。因此如果我們在 JavaScript 中有很多代碼，就必須創建用戶代理級的單元測試。我發現實現這種功能的最佳方法是使用 Microsoft? Internet Explorer? 內嵌的自動化層功能。通過使用 PHP 編寫的 Microsoft Windows? 腳本，可以使用組件對象模型(COM)接口來控制 Internet Explorer，讓它在頁面之間進行導航，然后使用文檔對象模型(DOM)方法在執行特定用戶操作之后查找頁面中的元素。

這是我了解的對前端 JavaScript 代碼進行單元測試的惟一一種方法。我承認它并不容易編寫和維護，這些測試即使在對頁面稍微進行改動時也很容易遭到破壞。

編寫哪些測試以及如何編寫這些測試

在編寫測試時，我喜歡覆蓋以下情況：

所有正面測試

這組測試可以確保所有的東西都如我們期望的一樣工作。

所有負面測試

逐一使用這些測試，從而確保每個失效或異常情況都被測試到了。

正面序列測試

這組測試可以確保按照正確順序的調用可以像我們期望的一樣工作。

負面序列測試

這組測試可以確保當不按正確順序進行調用時就會失敗。

負載測試

在適當情況下，可以執行一小組測試來確定這些測試的性能在我們期望的范圍之內。例如，2,000 次調用應該在 2 秒之內完成。

資源測試

這些測試確保應用編程接口(API)可以正確地分配并釋放資源 —— 例如，連續幾次調用打開、寫入以及關閉基于文件的 API，從而確保沒有文件依然是被打開的。

回調測試

對于具有回調方法的 API 來說，這些測試可以確保如果沒有定義回調函數，代碼可以正常運行。另外，這些測試還可以確保在定義了回調函數但是這些回調函數操作有誤或產生異常時，代碼依然可以正常運行。

這是有關單元測試的幾點想法。有關如何編寫單元測試，我也有幾點建議：

不要使用隨機數據

盡管在一個界面中產生隨機數據看起來貌似一個好主意，但是我們要避免這樣做，因為這些數據會變得非常難以調試。如果數據是在每次調用時隨機生成的，那么就可能產生一次測試時出現了錯誤而另外一次測試卻沒有出現錯誤的情況。如果測試需要隨機數據，可以在一個文件中生成這些數據，然后每次運行時都使用這個文件。采用這種方法，我們就獲得了一些 “噪音” 數據，但是仍然可以對錯誤進行調試。

分組測試

我們很容易累積起數千個測試，需要幾個小時才能執行完。這沒什么問題，但是對這些測試進行分組使我們可以快速運行某組測試并對主要關注的問題進行檢查，然后晚上運行完整的測試。

編寫穩健的 API 和穩健的測試

編寫 API 和測試時要注意它們不能在增加新功能或修改現有功能時很容易就會崩潰，這一點非常重要。這里沒有通用的絕招，但是有一條準則是那些 “振蕩的” 測試(一會兒失敗，一會兒成功，反復不停的測試)應該很快地丟棄。

結束語

單元測試對于工程師來說意義重大。它們是敏捷開發過程(這個過程非常強調編碼的作用，因為文檔需要一些證據證明代碼是按照規范進行工作的)的一個基礎。單元測試就提供了這種證據。這個過程從單元測試開始入手，這定義了代碼應該 實現但目前尚未實現的功能。因此，所有的測試最初都會失敗。然后當代碼接近完成時，測試就通過了。當所有測試全部通過時，代碼也就變得非常完善了。

我從來沒有在不使用單元測試的情況下編寫大型代碼或修改大型或復雜的代碼塊。我通常都是在修改代碼之前就為現有代碼編寫了單元測試，這樣可以確保自己清楚在修改代碼時破壞了什么(或者沒有破壞什么)。這為我對自己提供給客戶的代碼提供了很大的信心，相信它們正在正確運行 —— 即便是在凌晨 3 點。