HTML测试
对整个 PHP 应用程序进行测试的下一个步骤是对前端的超文本标记语言（HTML）界面进行测试。要进行这种测试，我们需要一个如下所示的 Web 页面。
这个页面对两个数字进行求和。为了对这个页面进行测试，我们首先从单元测试代码开始入手。
清单 10. TestPage.php
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( '//', $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( '//', $page ) == 1 );
preg_match( '/(.*?)/', $page, $out );
$this->assertTrue( $out[1]=='30' );
}
}
?>
这个测试使用了 PEAR 提供的 HTTP Client 模块。我发现它比内嵌的 PHP Client URL Library（CURL）更简单一点儿，不过也可以使用后者。
有一个测试会检查所返回的页面，并判断这个页面是否包含 HTML。第二个测试会通过将值放到请求的 URL 中来请求计算 10 和 20 的和，然后检查返回的页面中的结果。
这个页面的代码如下所示。
清单 11. TestPage.php
" /> +
" /> =
这个页面相当简单。两个输入域显示了请求中提供的当前值。结果 span 显示了这两个值的和。 标记标出了所有区别：它对于用户来说是不可见的，但是对于单元测试来说却是可见的。因此单元测试并不需要复杂的逻辑来找到这个值。相反，它会检索一个特定 标记的值。这样当界面发生变化时，只要 span 存在，测试就可以通过。
与前面一样，首先编写测试用例，然后创建一个失败版本的页面。我们对失败情况进行测试，然后修改页面的内容使其可以工作。结果如下：
清单 12. 测试失败情况，然后修改页面
% phpunit TestPage.php
PHPUnit 2.2.1 by Sebastian Bergmann.
..
Time: 0.25711488723755
OK (2 tests)
%
这两个测试都可以通过，这就意味着测试代码可以正常工作。
不过对 HTML 前端的测试有一个缺陷：Javascrīpt。超文本传输协议（HTTP）客户机代码对页面进行检索，但是却没有执行 Javascrīpt。因此如果我们在 Javascrīpt 中有很多代码，就必须创建用户代理级的单元测试。我发现实现这种功能的非常好的方法是使用 Microsoft? Internet Explorer? 内嵌的自动化层功能。通过使用 PHP 编写的 Microsoft Windows? 脚本，可以使用组件对象模型（COM）接口来控制 Internet Explorer，让它在页面之间进行导航，然后使用文档对象模型（DOM）方法在执行特定用户操作之后查找页面中的元素。
这是我了解的对前端 Javascrīpt 代码进行单元测试的惟一一种方法。我承认它并不容易编写和维护，这些测试即使在对页面稍微进行改动时也很容易遭到破坏。
编写哪些测试以及如何编写这些测试
在编写测试时，我喜欢覆盖以下情况：
所有正面测试
这组测试可以确保所有的东西都如我们期望的一样工作。
所有负面测试
逐一使用这些测试，从而确保每个失效或异常情况都被测试到了。
正面序列测试
这组测试可以确保按照正确顺序的调用可以像我们期望的一样工作。
负面序列测试
这组测试可以确保当不按正确顺序进行调用时就会失败。
负载测试
在适当情况下，可以执行一小组测试来确定这些测试的性能在我们期望的范围之内。例如，2,000 次调用应该在 2 秒之内完成。
资源测试
这些测试确保应用编程接口（API）可以正确地分配并释放资源 —— 例如，连续几次调用打开、写入以及关闭基于文件的 API，从而确保没有文件依然是被打开的。
回调测试
对于具有回调方法的 API 来说，这些测试可以确保如果没有定义回调函数，代码可以正常运行。另外，这些测试还可以确保在定义了回调函数但是这些回调函数操作有误或产生异常时，代码依然可以正常运行。
这是有关单元测试的几点想法。有关如何编写单元测试，我也有几点建议：
1.不要使用随机数据
尽管在一个界面中产生随机数据看起来貌似一个好主意，但是我们要避免这样做，因为这些数据会变得非常难以调试。如果数据是在每次调用时随机生成的，那么就可能产生一次测试时出现了错误而另外一次测试却没有出现错误的情况。如果测试需要随机数据，可以在一个文件中生成这些数据，然后每次运行时都使用这个文件。采用这种方法，我们就获得了一些 “噪音” 数据，但是仍然可以对错误进行调试。
2.分组测试
我们很容易累积起数千个测试，需要几个小时才能执行完。这没什么问题，但是对这些测试进行分组使我们可以快速运行某组测试并对主要关注的问题进行检查，然后晚上运行完整的测试。
3.编写稳健的 API 和稳健的测试
编写 API 和测试时要注意它们不能在增加新功能或修改现有功能时很容易就会崩溃，这一点非常重要。这里没有通用的绝招，但是有一条准则是那些 “振荡的” 测试（一会儿失败，一会儿成功，反复不停的测试）应该很快地丢弃。
结束语
单元测试对于工程师来说意义重大。它们是敏捷开发过程（这个过程非常强调编码的作用，因为文档需要一些证据证明代码是按照规范进行工作的）的一个基础。单元测试就提供了这种证据。这个过程从单元测试开始入手，这定义了代码应该 实现但目前尚未 实现的功能。因此，所有的测试最初都会失败。然后当代码接近完成时，测试就通过了。当所有测试全部通过时，代码也就变得非常完善了。
我从来没有在不使用单元测试的情况下编写大型代码或修改大型或复杂的代码块。我通常都是在修改代码之前就为现有代码编写了单元测试，这样可以确保自己清楚在修改代码时破坏了什么（或者没有破坏什么）。这为我对自己提供给客户的代码提供了很大的信心，相信它们正在正确运行 —— 即便是在凌晨 3 点。
