没有显示 getJDBCConnection() 方法，因为它的实现取决于希望如何获得 JDBC 连接：当 DataSource 为 Serializable 时通过应用服务器的 JNDI 树，或者直接使用 JDBC。

    getDbUnitConnection() 方法返回 DbUnit 的一个到数据库的连接。DbUnit 的 DatabaseConnection 构造函数可以带一个 schema 名作为参数。这样，不必在所有表名前面加上 schema 名的前缀了。

    getFlatXmlDataSet() 方法用位于类路径上的一个 XML 文件的内容创建 DbUnit 数据集。

后，该实际将数据插入测试表中。DbUnit 可以有不同的数据库操作，我使用了其中的两种：

    DELETE_ALL ，它删除表中所有行。
    CLEAN_INSERT ，它删除表中所有行并插入数据集提供的行。

ProjectDatabaseTestCase 中的下面四个方法可以满足您的需要：

    insertFileIntoDb() ：在数据库中插入文件。
    emptyTable() ：清理数据库表。
    insertAllFilesIntoDb() ：插入项目的所有文件。
    emptyAllTables() ：清理项目的所有表。

完成了基类后，用 DbUnit 干净地建立数据库，执行一个方法，并检查返回值是很容易的事。

在这个测试中，我清空了数据库，插入一个表的内容，并通过检查它返回的元素是否有正确的属性来检查用主键查找产品的 finder 方法是否正常工作。然后测试对象创建工作，并用 DbUnit 的查询程序验证数据库的内容。

需要注意的一件重要事情是，清理数据库是在建立测试而不是结束时进行的。我不想依赖于每次测试都干净地结束。

在插入数据时要关注的事情

数据库完整性约束迫使您以给定的顺序插入或者删除数据。在编写 insertAllFiles() 和 emptyAllTables() 方法时，您会发现顺序并非是随意的，事实上它是由完整性约束所限定的。

另一个潜在的陷井是，一些列可能看来没有插入。几乎总是会出现这种情况，因为在 FlatXmlDataSet 中的第一行缺少一列。看来 DbUnit 不能识别所有其他行中的这一列。

总是要保证第一行描述包含表中的所有列。如果需要插入一个 NULL 值，要使这一行成为第二行。

组织测试数据

DbUnit 可以在文件中存储 XML 数据集。它甚至允许在一个文件中存储整个数据库。

决定如何存储测试数据很重要。是将每一个表的内容存储到单独的文件中，还是将与系统主要实体有关的所有表的所有行存储到一个文件中？它们都不是完美的解决方案（silver bullet）。

对于第一种情况，保证跨表的数据一致更困难，但是用一个已经存在的数据库创建查询更容易。在第二种情况下，为每一个测试创建测试集更容易，但是事实上大多数系统不是围绕一个主要实体设计的，因此这使它不那么实用。我们的方法是每个表有一个文件。

 
用 Anthill 实现持续集成

Anthill 是一个免费的自动构建工具（请参阅 参考资料），它规划您的构建并发布结果，帮助精通 XP 的小组使用持续集成。一次构建包含用 CVS 这样的版本控制工具检查源代码、运行一个构建脚本、发布结果并通知用户结果。它很好地与 ANT 集成，使您可以重用常用的构建脚本。

在 Anthill 中运行测试包并报告结果

XP 专家一直建议将持续集成作为确保减少集成错误一种方式：通过以足够高的频率集成所有代码，保证容易追溯到源代码中的问题。集成可能是非常耗时的任务--检查、构建和部署代码，然后运行验收试验。幸运的是，其中大多数可以用 Anthill 或者 CruiseControl 这样的工具自动化。如果还没有使构建过程自动化（例如用 Ant)，那您应当这样做。如果构建过程是自动化的，应当在构建中加入一个测试部分。如果您是顽固的 XP 用户，这些应当是您的验收测试。如果您像我们一样，那么这些是您要编写的所有测试--不管是单元、验收或者其他测试。

我们的构建过程基于 Ant 并计划使用 Anthill。我们的主要挑战是让 Anthill 报告失败的测试并且仍然发布测试结果。Anthill 捕获的是：如果构建脚本失败，不执行发布脚本，在这种情况下不能将测试报告提供给开发人员。我们的方法是让 Anthill 检查属性为 true 还是 false，而使它在发布脚本的后才失败。

运行测试的目标

下面是关于运行测试的简要总结。我们使用的是批量化的方法，但是任何方法都可以工作。要点有：

    测试必须具有分支，以便在类路径包含 JDK 1.3 中的 XML 解析器时可以正常工作。
    如果出现错误或者失败，则 testsuite.error 和 testsuite.failure 属性必须设置为 true。如果没有错误或者失败的话，则不改变它们。

一个需要了解的重要的 Ant 技巧是，Ant 只在属性没有值时才设置属性的值。所以在依次运行每一个测试时， testsuite.error 和 testsuite.failure 属性只有当出现错误或者失败时才会是 true。

这里的困难是向主 Ant 脚本报告测试脚本的结果。不幸的是，这并不是一项简单的任务，因为在 Anthill 的过程中有两个不同的 Ant 构建文件，在 Ant 中不能在构建脚本之间传递这种参数。不过，有一个“简单”的解决方案：将测试的结果保存到文件中，之后发布脚本读取这个文件。

使用这种 Ant 技巧，它显示了如何使用 <property> 命令保证 testsuite.error 和 testsuite.failure 属性在测试脚本结束时总是有一个值，以及如何将它保存为文件。

如果测试失败，使发布脚本在结束时失败。

结束语

我们的小组成功地在 2003 年初引入了 DbUnit 和 Anthill。从那以后，我们编写并自动化了上千次测试--其中 75% 涉及设置数据库状态。我们每小时运行一次测试，并计划很快以更短的周期运行它们。它们捕获了很多未预料到的缺陷，这使它们成为不可缺少的工具。