| UML软件工程组织 | |||
| |
|||
|
|||
利用单元测试在每个层上对PHP代码进行检查
作者:Jack D. Herrington 出处:网络
| 测试驱动的开发和单元测试是确保代码在经过修改和重大调整之后依然能如我们期望的一样工作的最新方法。在本文中，您将学习到如何在模块、数据库和用户界面（UI）层对自己的PHP代码进行单元测试。现在是凌晨3点。我们怎样才能知道自己的代码依然在工作呢？ 单元测试是一个为代码编写测试用例并自动运行这些测试的框架。测试驱动的开发是一种单元测试方法，其思想是应该首先编写测试程序，并验证这些测试可以发现错误，然后才开始编写需要通过这些测试的代码。当所有测试都通过时，我们开发的特性也就完成了。这些单元测试的价值是我们可以随时运行它们——在签入代码之前，重大修改之后，或者部署到正在运行的系统之后都可以。 PHP单元测试 对于PHP来说，单元测试框架是PHPUnit2。可以使用PEAR命令行作为一个PEAR模块来安装这个系统：% pear install PHPUnit2。 在安装这个框架之后，可以通过创建派生于PHPUnit2_Framework_TestCase的测试类来编写单元测试。 模块单元测试 我发现开始单元测试最好的地方是在应用程序的业务逻辑模块中。我使用了一个简单的例子：这是一个对两个数字进行求和的函数。为了开始测试，我们首先编写测试用例，如下所示。 清单1.TestAdd.php
这个TestAdd类有两个方法，都使用了test前缀。每个方法都定义了一个测试，这个测试可以与清单1一样简单，也可以十分复杂。在本例中，我们在第一个测试中只是简单地断定1加2等于3，在第二个测试中是1加1等于2。 PHPUnit2系统定义了assertTrue()方法，它用来测试参数中包含的条件值是否为真。然后，我们又编写了Add.php模块，最初让它产生错误的结果。 清单2.Add.php
现在运行单元测试时，这两个测试都会失败。 清单3.测试失败
现在我知道这两个测试都可以正常工作了。因此，可以修改add()函数来真正地做实际的事情了。 function add( $a, $b ) { return $a+$b; }?> 现在这两个测试都可以通过了。 清单4.测试通过
尽管这个测试驱动开发的例子非常简单，但是我们可以从中体会到它的思想。我们首先创建了测试用例，并且有足够多的代码让这个测试运行起来，不过结果是错误的。然后我们验证测试的确是失败的，接着实现了实际的代码使这个测试能够通过。 我发现在实现代码时我会一直不断地添加代码，直到拥有一个覆盖所有代码路径的完整测试为止。在本文的最后，您会看到有关编写什么测试和如何编写这些测试的一些建议。 数据库测试 在进行模块测试之后，就可以进行数据库访问测试了。数据库访问测试带来了两个有趣的问题。首先，我们必须在每次测试之前将数据库恢复到某个已知点。其次，要注意这种恢复可能会对现有数据库造成破坏，因此我们必须对非生产数据库进行测试，或者在编写测试用例时注意不能影响现有数据库的内容。 数据库的单元测试是从数据库开始的。为了阐述这个问题，我们需要使用下面的简单模式。 清单5.Schema.sql
清单5是一个authors表，每条记录都有一个相关的ID。 接下来，就可以编写测试用例了。 清单6.TestAuthors.php
这组测试覆盖了从表中删除作者、向表中插入作者以及在验证作者是否存在的同时插入作者等功能。这是一个累加的测试，我发现对于寻找错误来说这非常有用。观察一下哪些测试可以正常工作，而哪些测试不能正常工作，就可以快速地找出哪些地方出错了，然后就可以进一步理解它们之间的区别。 最初产生失败的dblib.php PHP数据库访问代码版本如下所示。 清单7.dblib.php
对清单8中的代码执行单元测试会显示这3个测试全部失败了： 清单8.dblib.php
现在我们可以开始添加正确访问数据库的代码——一个方法一个方法地添加——直到所有这3个测试都可以通过。最终版本的dblib.php代码如下所示。 清单9.完整的dblib.php
在对这段代码运行测试时，所有的测试都可以没有问题地运行，这样我们就可以知道自己的代码可以正确工作了。 HTML测试 对整个PHP应用程序进行测试的下一个步骤是对前端的超文本标记语言（HTML）界面进行测试。要进行这种测试，我们需要一个如下所示的Web页面。 这个页面对两个数字进行求和。为了对这个页面进行测试，我们首先从单元测试代码开始入手。 清单10.TestPage.php
这个测试使用了PEAR提供的HTTP Client模块。我发现它比内嵌的PHP Client URL Library（CURL）更简单一点儿，不过也可以使用后者。 有一个测试会检查所返回的页面，并判断这个页面是否包含HTML。第二个测试会通过将值放到请求的URL中来请求计算10和20的和，然后检查返回的页面中的结果。 这个页面的代码如下所示。 清单11.TestPage.php
这个页面相当简单。两个输入域显示了请求中提供的当前值。结果span显示了这两个值的和。标记标出了所有区别：它对于用户来说是不可见的，但是对于单元测试来说却是可见的。因此单元测试并不需要复杂的逻辑来找到这个值。相反，它会检索一个特定标记的值。这样当界面发生变化时，只要span存在，测试就可以通过。 与前面一样，首先编写测试用例，然后创建一个失败版本的页面。我们对失败情况进行测试，然后修改页面的内容使其可以工作。结果如下： 清单12.测试失败情况，然后修改页面
这两个测试都可以通过，这就意味着测试代码可以正常工作。 不过对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点。 |
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
