你是否在程序开发的过程中遇到以下的情况：当你花了很长的时间开发一个PHP应用后，你认为应该是大功告成了，可惜在调试的时候，老是不断的发现bug，而且最可怕的是，这些bug是重复出现的，你可能发现这些bug...     

　　你是否在程序开发的过程中遇到以下的情况：当你花了很长的时间开发一个PHP应用后，你认为应该是大功告成了，可惜在调试的时候，老是不断的发现bug，而且最可怕的是，这些bug是重复出现的，你可能发现这些bug之间会有关联，但却老是找不到问题的所在。

　　当你遇到以上这些令你沮丧的情况时，你一定会想能有什么更好的办法去解决呢?办法当然是有的!这就是使用单元测试。单元测试不但可以在一定程度上解决上述头疼的问题，而且能让代码变的容易维护，还可以能让你更多地对代码进行重构。

　　一旦你编写好单元测试用例，当你需要修改你的代码时，你要做的事情就是重新运行你的单元测试用例并观察这些单元测试用例能否通过，如果通过了的话，证明代码是没问题的。

　　人们往往会说：既然单元测试这么好，为什么那么多人还是不大愿意去写单元测试呢?有以下几种理解上的误曲：

　　1、认为编写单元测试太浪费时间。虽然目前很多IDE工具都为编写单元测试建立好了框架，但还是要开发者编写一些单元测试的代码的。就象很多开发中的最佳实践一样，用正确的方法去做正确的事情会为开发节省大量的时间。每当新增加新功能时，你可能通过访问你的网页到处去点击手动测试，而运行建立好的单元测试用例其速度其实比通过手工去测试的速度更快。

　　2、认为既然代码能运行了，不需要再编写单元测试。但假设团队中有新的成员，如果没有良好的单元测试用例，新成员很有可能随意地去编码而不考虑各种后果。如果有编写良好的单元测试，在程序运行时进行各种测试，则能最大程度避免bug的产生。

　　3、认为编写单元测试代码枯燥无味。程序员的天性是解决问题，而很多程序员认为在紧张的编码工作时，还要编写单元测试代码，会很枯燥。但要知道的是，如果能通过编写单元测试在很早的阶段就能尽可能发现代码中多的错误的话，那么既节省时间减少了出错，何乐而不为?

　　开始动手安装PHPUnit

　　本文中将通过介绍PHP中的单元测试利器PHPUnit(http://phpunit.de/),并通过实际例子来讲解如何在实际工作中运用PHPUnit。首先安装PHPUnit的方法可以通过PHP下的pear去安装：如果你想通过手动方式去安装，可以参考PHPUnit的手册去安装(http://www.phpunit.de/manual/3.0/en/installation.html)。

　　编写第一个单元测试用例

　　下面我们开始编写第一个单元测试用例。在编写测试用例时，要遵守如下的PHPUnit的规则：

　　1　一般地，在测试用例中，可以扩展PHPUnit_Framework_TestCase类，这样就可以使用象setUp(),tearDown()等方法了。

　　2 测试用例的名字最好是使用约定俗成的格式，即在被测试类的后面加上”Test”,比如要测试的类为RemoteConnect,则测试用例的命名为RemoteConnectTest。

　　3 在一个测试用例中的所有的测试方法，在命名时都应该以test+测试方法名去命名，如testDoesLikeWaffles(),要注意的是该方法必须是声明为public类型的。当然可以在你的测试用例中包含private的方法，但它们不能被phpunit所调用。

　　4 测试方法中是不能接收参数的。

　　下面首先举个简单的例子，代码如下：面的代码其实是实现连接到一个指定的服务器的功能，那么我们可以编写测试代码如下：在上面的代码中，由于继承了PHPUnit_Framework_TestCase类，因此在setUp和tearDown方法中，不需要编写任何代码。SetUp方法是在每个测试用例运行前进行一些初始化的工作，而tearDown则在每个测试用例运行后进行一些比如资源的释放等工作。在测试方法中，通过使用PHPUnit的断言assertTrue去判断所返回的布尔值是否为真，这里是通过调用RemoteConnect.php中的connectToServe方法去判断能否连接上服务器。

　　接下来我们运行这个单元测试，在命令行下输入代码：

　　phpunit /path/to/tests/RemoteConnectTest.php即可，可以看到测试顺利通过的话，会输出以下结果：可以看到，上面是通过了测试。默认情况下，PHPUnit是会运行测试用例中的所有测试方法的。下面再介绍下PHPUnit中相关的几个断言：

　　AssertTrue/AssertFalse 断言是否为真值还是假

　　AssertEquals 判断输出是否和预期的相等

　　AssertGreaterThan 断言结果是否大于某个值，同样的也有LessThan(小于),GreaterThanOrEqual(大于等于)，

　　LessThanOrEqual(小于等于).

　　AssertContains 判断输入是否包含指定的值

　　AssertType 判断是否属于指定类型

　　AssertNull 判断是否为空值

　　AssertFileExists 判断文件是否存在

　　AssertRegExp 根据正则表达式判断

　　举个例子来说明下比如AssertType的使用，依然以上面的例子来说，可以用AssertType去判断returnSampleObject返回的对象实例是否为remoteConnect，代码如下：目前PHP框架对单元测试的支持

　　目前很多优秀的PHP框架(如Zend Framework,Symfony等)，都提供了对单元测试很好的支持。以Zend Framework为例，说明下其中是如何运行单元测试的。以上代码其实是对Zend本身的框架进行了一个单元测试而已，可以看到，在Zend中，是通过继承Zend_Test_PHPUnit_ControllerTestCase去对Zend的controller去进行单元测试的，可以看到，在zend中的单元测试跟PHPUnit中的差不多，但增加了另外一些新的断言，比如上面的assertController,具体的可以参考Zend的参考手册。

　　PHPUnit是一个轻量级的PHP测试框架。它是在PHP5下面对JUnit3系列版本的完整移植，是xUnit测试框架家族的一员(它们都基于模式先锋Kent Beck的设计)。

　　单元测试是几个现代敏捷开发方法的基础，使得PHPUnit成为许多大型PHP项目的关键工具。这个工具也可以被Xdebug扩展用来生成代码覆盖率报告 ，并且可以与phing集成来自动测试，最后它还可以和Selenium整合来完成大型的自动化集成测试

　如果只有一种方式使用数据库是正确的，您可以用很多的方式创建数据库设计、数据库访问和基于数据库的 PHP 业务逻辑代码，但最终一般以错误告终。本文说明了数据库设计和访问数据库的 PHP 代码中出现的五...     　　如果只有一种方式使用数据库是正确的，您可以用很多的方式创建数据库设计、数据库访问和基于数据库的 PHP 业务逻辑代码，但最终一般以错误告终。本文说明了数据库设计和访问数据库的 PHP 代码中出现的五个常见问题，以及在遇到这些问题时如何修复它们。

　　问题 1：直接使用 MySQL

　　一个常见问题是较老的 PHP 代码直接使用 mysql_ 函数来访问数据库。清单 1 展示了如何直接访问数据库。

　　清单 1. Access/get.php注意使用了 mysql_connect 函数来访问数据库。还要注意查询，其中使用字符串连接来向查询添加 $name 参数。

　　该技术有两个很好的替代方案：PEAR DB 模块和 PHP Data Objects (PDO) 类。两者都从特定数据库选择提供抽象。因此，您的代码无需太多调整就可以在 IBM® DB2®、MySQL、PostgreSQL 或者您想要连接到的任何其他数据库上运行。

　　使用 PEAR DB 模块和 PDO 抽象层的另一个价值在于您可以在 SQL 语句中使用 ? 操作符。这样做可使 SQL 更加易于维护，且可使您的应用程序免受 SQL 注入攻击。

　　使用 PEAR DB 的替代代码如下所示。

　　清单 2. Access/get_good.php注意，所有直接用到 MySQL 的地方都消除了，只有 $dsn 中的数据库连接字符串除外。此外，我们通过 ? 操作符在 SQL 中使用 $name 变量。然后，查询的数据通过 query() 方法末尾的 array 被发送进来。

　　问题 2：不使用自动增量功能

　　与大多数现代数据库一样，MySQL 能够在每记录的基础上创建自动增量惟一标识符。除此之外，我们仍然会看到这样的代码，即首先运行一个 SELECT 语句来找到最大的 id，然后将该 id 增 1，并找到一个新记录。清单 3 展示了一个示例坏模式。

　　清单 3. Badid.sql这里的 id 字段被简单地指定为整数。所以，尽管它应该是惟一的，我们还是可以添加任何值，如 CREATE 语句后面的几个 INSERT 语句中所示。清单 4 展示了将用户添加到这种类型的模式的 PHP 代码。

　　清单 4. Add_user.phpadd_user.php 中的代码首先执行一个查询以找到 id 的最大值。然后文件以 id 值加 1 运行一个 INSERT 语句。该代码在负载很重的服务器上会在竞态条件中失败。另外，它也效率低下。

　　那么替代方案是什么呢?使用 MySQL 中的自动增量特性来自动地为每个插入创建惟一的 ID。更新后的模式如下所示。

　　清单 5. Goodid.php我们添加了 NOT NULL 标志来指示字段必须不能为空。我们还添加了 AUTO_INCREMENT 标志来指示字段是自动增量的，添加 PRIMARY KEY 标志来指示那个字段是一个 id。这些更改加快了速度。清单 6 展示了更新后的 PHP 代码，即将用户插入表中。

　　清单 6. Add_user_good.php现在我不是获得最大的 id 值，而是直接使用 INSERT 语句来插入数据，然后使用 SELECT 语句来检索最后插入的记录的 id。该代码比最初的版本及其相关模式要简单得多，且效率更高。

　　问题 3：使用多个数据库

　　偶尔，我们会看到一个应用程序中，每个表都在一个单独的数据库中。在非常大的数据库中这样做是合理的，但是对于一般的应用程序，则不需要这种级别的分割。此外，不能跨数据库执行关系查询，这会影响使用关系数据库的整体思想，更不用说跨多个数据库管理表会更困难了。

　　那么，多个数据库应该是什么样的呢?首先，您需要一些数据。清单 7 展示了分成 4 个文件的这样的数据。

　　清单 7. 数据库文件在这些文件的多数据库版本中，您应该将 SQL 语句加载到一个数据库中，然后将 users SQL 语句加载到另一个数据库中。用于在数据库中查询与某个特定用户相关联的文件的 PHP 代码如下所示。

　　清单 8. Getfiles.phpget_user 函数连接到包含用户表的数据库并检索给定用户的 ID。get_files 函数连接到文件表并检索与给定用户相关联的文件行。

　　做所有这些事情的一个更好办法是将数据加载到一个数据库中，然后执行查询，比如下面的查询。

　　清单 9. Getfiles_good.php该代码不仅更短，而且也更容易理解和高效。我们不是执行两个查询，而是执行一个查询。

　　尽管该问题听起来有些牵强，但是在实践中我们通常总结出所有的表应该在同一个数据库中，除非有非常迫不得已的理由。

　　问题 4：不使用关系

　　关系数据库不同于编程语言，它们不具有数组类型。相反，它们使用表之间的关系来创建对象之间的一到多结构，这与数组具有相同的效果。我在应用程序中看到的一个问题是，工程师试图将数据库当作编程语言来使用，即通过使用具有逗号分隔的标识符的文本字符串来创建数组。请看下面的模式。

　　清单 10. Bad.sql[/code]　　系统中的一个用户可以具有多个文件。在编程语言中，应该使用数组来表示与一个用户相关联的文件。在本例中，程序员选择创建一个 files 字段，其中包含一个由逗号分隔的文件 id 列表。要得到一个特定用户的所有文件的列表，程序员必须首先从用户表中读取行，然后解析文件的文本，并为每个文件运行一个单独的 SELECT 语句。该代码如下所示。

　　清单 11. Get.php该技术很慢，难以维护，且没有很好地利用数据库。惟一的解决方案是重新架构模式，以将其转换回到传统的关系形式，如下所示。

　　清单 12. Good.sql这里，每个文件都通过 user_id 函数与文件表中的用户相关。这可能与任何将多个文件看成数组的人的思想相反。当然，数组不引用其包含的对象 —— 事实上，反之亦然。但是在关系数据库中，工作原理就是这样的，并且查询也因此要快速且简单得多。清单 13 展示了相应的 PHP 代码。

　　清单 13. Get_good.php这里，我们对数据库进行一次查询，以获得所有的行。代码不复杂，并且它将数据库作为其原有的用途使用.

　　问题 5：n+1 模式

　　我真不知有多少次看到过这样的大型应用程序，其中的代码首先检索一些实体(比如说客户)，然后来回地一个一个地检索它们，以得到每个实体的详细信息。我们将其称为 n+1 模式，因为查询要执行这么多次 —— 一次查询检索所有实体的列表，然后对于 n 个实体中的每一个执行一次查询。当 n=10 时这还不成其为问题，但是当 n=100 或 n=1000 时呢?然后肯定会出现低效率问题。清单 14 展示了这种模式的一个例子。

　　清单 14. Schema.sql该模式是可靠的，其中没有任何错误。问题在于访问数据库以找到一个给定作者的所有书籍的代码中，如下所示。

　　清单 15. Get.php如果您看看下面的代码，您可能会想，“嘿，这才是真正的清楚明了。” 首先，得到作者 id，然后得到书籍列表，然后得到有关每本书的信息。的确，它很清楚明了，但是其高效吗?回答是否定的。看看只是检索 Jack Herrington 的书籍时要执行多少次查询。一次获得 id，另一次获得书籍列表，然后每本书执行一次查询。三本书要执行五次查询!

　　解决方案是用一个函数来执行大量的查询，如下所示。

　　清单 16. Get_good.php[/code]　　现在检索列表需要一个快速、单个的查询。这意味着我将很可能必须具有几个这些类型的具有不同参数的方法，但是实在是没有选择。如果您想要具有一个扩展的 PHP 应用程序，那么必须有效地使用数据库，这意味着更智能的查询。

　　本例的问题是它有点太清晰了。通常来说，这些类型的 n+1 或 n*n 问题要微妙得多。并且它们只有在数据库管理员在系统具有性能问题时在系统上运行查询剖析器时才会出现。

　　结束语

　　数据库是强大的工具，就跟所有强大的工具一样，如果您不知道如何正确地使用就会滥用它们。识别和解决这些问题的诀窍是更好地理解底层技术。长期以来，我老听到业务逻辑编写人员抱怨，他们不想要必须理解数据库或 SQL 代码。他们把数据库当成对象使用，并疑惑性能为什么如此之差。

　　他们没有认识到，理解 SQL 对于将数据库从一个困难的必需品转换成强大的联盟是多么重要。如果您每天使用数据库，但是不熟悉 SQL，那么请阅读 The Art of SQL，这本书写得很好，实践性也很强，可以指导您基本了解数据库。

关键词：测试利器