這個測試使用了 PEAR 提供的 HTTP Client 模塊。我發(fā)現(xiàn)它比內(nèi)嵌的 PHP Client URL Library（CURL）更簡單一點兒，不過也可以使用后者。
有一個測試會檢查所返回的頁面，并判斷這個頁面是否包含 HTML。第二個測試會通過將值放到請求的 URL 中來請求計算 10 和 20 的和，然后檢查返回的頁面中的結(jié)果。
這個頁面的代碼如下所示。
清單 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>
這個頁面相當簡單。兩個輸入域顯示了請求中提供的當前值。結(jié)果 span 顯示了這兩個值的和。<span>標記標出了所有區(qū)別：它對于用戶來說是不可見的，但是對于單元測試來說卻是可見的。因此單元測試并不需要復雜的邏輯來找到這個值。相反，它會檢索一個特定<span>標記的值。這樣當界面發(fā)生變化時，只要 span 存在，測試可以通過。
與前面一樣，首先編寫測試用例，然后創(chuàng)建一個失敗版本的頁面。我們對失敗情況進行測試，然后修改頁面的內(nèi)容使其可以工作。結(jié)果如下：
清單 12. 測試失敗情況，然后修改頁面
% phpunit TestPage.php
PHPUnit 2.2.1 by Sebastian Bergmann.
..
Time: 0.25711488723755
OK (2 tests)
%
這兩個測試都可以通過，這意味著測試代碼可以正常工作。
在對這段代碼運行測試時，所有的測試都可以沒有問題地運行，這樣我們可以知道自己的代碼可以正確工作了。
不過對 HTML 前端的測試有一個缺陷：JavaScript。超文本傳輸協(xié)議（HTTP）客戶機代碼對頁面進行檢索，但是卻沒有執(zhí)行 JavaScript。因此如果我們在 JavaScript. 中有很多代碼，必須創(chuàng)建用戶代理級的單元測試。我發(fā)現(xiàn)實現(xiàn)這種功能的佳方法是使用 Microsoft® Internet Explorer® 內(nèi)嵌的自動化層功能。通過使用 PHP 編寫的 Microsoft Windows® 腳本，可以使用組件對象模型（COM）接口來控制 Internet Explorer，讓它在頁面之間進行導航，然后使用文檔對象模型（DOM）方法在執(zhí)行特定用戶操作之后查找頁面中的元素。
這是我了解的對前端 JavaScript. 代碼進行單元測試的惟一一種方法。我承認它并不容易編寫和維護，這些測試即使在對頁面稍微進行改動時也很容易遭到破壞。
編寫哪些測試以及如何編寫這些測試
在編寫測試時，我喜歡覆蓋以下情況：
所有正面測試
這組測試可以確保所有的東西都如我們期望的一樣工作。
所有負面測試
逐一使用這些測試，從而確保每個失效或異常情況都被測試到了。
正面序列測試
這組測試可以確保按照正確順序的調(diào)用可以像我們期望的一樣工作。
負面序列測試
這組測試可以確保當不按正確順序進行調(diào)用時會失敗。
負載測試
在適當情況下，可以執(zhí)行一小組測試來確定這些測試的性能在我們期望的范圍之內(nèi)。例如，2，000 次調(diào)用應該在 2 秒之內(nèi)完成。
資源測試
這些測試確保應用編程接口（API）可以正確地分配并釋放資源 —— 例如，連續(xù)幾次調(diào)用打開、寫入以及關(guān)閉基于文件的 API，從而確保沒有文件依然是被打開的。
回調(diào)測試
對于具有回調(diào)方法的 API 來說，這些測試可以確保如果沒有定義回調(diào)函數(shù)，代碼可以正常運行。另外，這些測試還可以確保在定義了回調(diào)函數(shù)但是這些回調(diào)函數(shù)操作有誤或產(chǎn)生異常時，代碼依然可以正常運行。
