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

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

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

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

PHP 單元測試

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

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

模塊單元測試

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

清單 1. TestAdd.php

require_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

function add( $a, $b ) { return 0; }

?>

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

清單 3. 測試失敗

% phpunit TestAdd.php

PHPUnit 2.2.1 by Sebastian Bergmann.

FF

Time: 0.0031270980834961

There were 2 failures:

1) test1(TestAdd)

2) test2(TestAdd)

FAILURES!!!

Tests run: 2, Failures: 2, Errors: 0, Incomplete Tests: 0.

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

function add( $a, $b ) { return $a $b; }

?>

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

清單 4. 測試通過

% phpunit TestAdd.php

PHPUnit 2.2.1 by Sebastian Bergmann.

..

Time: 0.0023679733276367

OK (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

require_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

require_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.php

PHPUnit 2.2.1 by Sebastian Bergmann.

FFF

Time: 0.007500171661377

There 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.

%