DbUnit
　　DbUnit扩展大大简化了为测试设置数据库的操作，并且可以在对数据执行了一系列操作之后验证数据库的内容。
　　DbUnit所支持的供应商
　　DbUnit 目前支持 MySQL、PostgreSQL、Oracle 和 SQLite。通过集成 Zend Framework 或 Doctrine 2，也可以访问其他数据库系统，比如 IBM DB2 或者 Microsoft SQL Server。
　　数据库测试的难点
　　为什么所有单元测试的范例都不包含数据库交互？这里有个很好的理由：这类测试的建立和维护都很复杂。对数据库进行测试时，需要考虑以下这些变数：
　　· 数据库和表
　　· 向表中插入测试所需要的行
　　· 测试运行完毕后验证数据库的状态
　　· 每个新测试都要清理数据库
　　许多数据库 API，比如 PDO、MySQLi 或者 OCI8，都十分繁琐且书写起来十分冗长，因此，手工进行这些步骤是噩梦。
　　测试代码应当尽可能简短精确，这有若干原因：
　　· 你不希望因为生产代码的小变更而需要对测试代码进行数量可观的修改。
　　· 你希望在哪怕好几个月以后也能轻松地阅读并理解测试代码。
　　另外，必须认识到，对于代码而言，本质上来说数据库是全局输入变量。测试套件中的两个不同的测试可能是运行在同一个数据库上的，并且可能把数据重用好多次。一个测试中出现的失败很容易影响到后继测试的结果，从而让整个测试过程变得非常艰难。前面提到的清理步骤对于解决“数据库是全局输入”的问题是非常重要的。
　　DbUnit 以一种优雅的方式来帮助简化数据库测试中的所有这些问题。
　　PHPUnit 无法帮你解决的问题是，相对于不使用数据的测试而言，数据库测试是非常慢的。随着数据库交互规模的增大，运行测试可能需要耗费可观的时间。然而，只要保持每个测试所使用的数据量较小并且尽可能用非数据库测试来对代码进行测试，即使很大的测试套件也能轻松在一分钟内跑完。
　　数据库测试的四个阶段
　　Gerard Meszaros 在他的书《xUnit 测试模式》中列出了单元测试的四个阶段：
　　· 建立基架(fixture)
　　· 执行被测系统
　　· 验证结果
　　· 拆除基架(fixture)
　　什么是基架(fixture)？
　　基架(fixture)是对开始执行某个测试时应用程序和数据库所处初始状态的描述。
　　对数据库进行测试至少要处理建立与拆除的步骤，在其中完成清理工作，并将所需的基架数据写入表内。然而对于数据库扩展模块而言，在数据库测试中有很好的理由将这四个步骤还原成类似下面这样的工作流程，这个流程对于每个测试都会完整执行：
　　清理数据库
　　由于总是会有某个测试运行在并不确定表中是否有数据的数据库上，PHPUnit 在所有指定表上执行 TRUNCATE 操作来把它们清空。
　　建立基架
　　PHPUnit 随后将迭代所有指定的基架数据行并将其插入到对应的表里。
　　3–5. 运行测试、验证结果、并拆除基架
　　在所有数据库都完成重置并加载好初始状态后，PHPUnit 才会执行实际的测试。这个部分的测试代码完全不需要数据库扩展模块的参与，可以随意测试任何想要测试的内容。
　　在测试中，验证的目的可以使用一个名为 assertDataSetsEqual() 的特殊断言来实现。当然，这完全是可选的。
　　一些术语
　　· 单元测试
　　· 集成测试
　　· 回归测试
　　· 测试用例
　　· 断言
　　· 基架Fixture