测试 J2EE 数据库应用程序的最佳实践

在附带的源代码中，TestListPersons 类包含用于 listPersons() 方法的一组相当全面的测试的一个示例，有兴趣的读者有空时可仔细研读一下。

试一试。在 Oracle JDeveloper 中，打开 PersonDAOImpl 的实现类以及测试类 TestListPersons。试着在实现中找到一种没有为任何测试所覆盖的情景。

最佳实践 5：创建稳定、有意义的测试数据集

花些时间和精力创建一个稳定、有意义的测试数据集，您的测试将以该测试数据集为基础。 有了好的测试数据，编写数据库测试也就容易得多了。开发人员知道他们会得到所需的数据，因此也就可以信心十足地作出精确断言。

创建测试数据是在 TDD 环境中进行数据库开发的一个基础。对数据库操作而言，开发应是测试数据驱动的。在为用例编写测试之前，构建一个数据集。测试数据集并不总是需要很大；它只需足够覆盖与要测试的操作相关的情景。

创建测试数据可能是一项单调乏味的工作，但值得投入时间和脑力创建有意义且结构合理的数据。如果您在项目的早期就创建了高质量的数据，那么您将发现当您向应用程序中添加新特性和测试时可以更容易地更改、扩展或重用您的工作成果。好的测试数据对用户界面测试也极其有用。

应用最佳实践。您可以通过输入 SQL INSERT 语句或使用工具将数据导入成这种格式来轻松地创建测试数据。然而，为了实现测试自动化，您将需要一种易于从 JUnit 测试案例内部访问的数据插入和删除机制。您可以使用以下任一方式：

• 从 JUnit 内部运行 SQL*Plus 或 SQL*Loader 脚本。附带的源代码就使用了这种方法。有兴趣的读者可以看一下 SqlPlusRunner 的实现。它通过一个单独的 Java 过程运行了一个 SQL*Plus 脚本。
• ANT SQL 任务。
• 定制的测试数据加载程序。这种加载程序从文本文件中读取 SQL 命令并通过 JDBC 执行它们。
• 库，如 DbUnit，它是专门设计用来简化数据库测试的一个 JUint 扩展。DbUnit 允许将测试数据从 XML 文件导入到数据库中，并且还允许将数据库中的数据导出成 XML 和其他格式。
• 应用程序的 API 本身。当然，没有该 API 的实际实现，您就无法使用这种机制。

在我们的示例应用程序中，您使用从 Java 内部启动的 SQL*Plus 加载测试类的 setUp() 方法中的测试数据，如清单 3 所示。

代码清单 3： setup() 方法与 SqlPlusRunner

protected void setUp() throws Exception 
{
	super.setUp();
	SqlPlusRunner.runSQLPlusFile("truncate_data.sql");
	assertEquals(0,SqlPlusRunner.runSQLPlusFile("persons_data.sql"));
	...
}

注意在测试运行之前对 SqlPlusRunner 的第一次调用如何从相关的表中删除现有的数据（通过调用 truncate_data.sql 文件）。接下来对 SqlPlusRunner 的调用将插入测试本身所需的数据（通过调用 persons_data.sql 文件）。

试一试。在 Applications Navigator 视图中，打开 Resources 节点。您将看到几个 SQL 文件（如图 2 所示）。这些文件包含了项目的测试数据以及用于截除数据、创建和删除表的脚本。这些脚本将作为测试环境的一部分来运行，并且还可以用 SQL*Plus 单独运行。

图 2：用于创建测试数据的资源

如果您不应用它. . . 如果不保证在项目的早期创建有意义的数据，那么您将发现自己不得不重复地（经常是没有必要地）为新测试创建新数据，从而导致易可管理性和强健性较差的测试环境。

最佳实践 6：创建专用的测试库

创建一个专门支持数据库测试的类库可以大大减轻测试的负担。作为编写数据库测试的开发人员，您可能发现自己为支持测试编写了大量的代码。例如，您将需要获取和释放数据库连接。您将需要启动和结束事务。您还经常需要在运行测试之后运行数据库状态查询。有时您将需要在运行数据库测试前执行修改数据库状态的操作，特别是您在一个无法在测试运行之前清理和重新插入数据的环境中工作时。

在所有这些情况下，您都将因专用测试库 — 包含在测试源文件夹中的一个类库，完全为简化测试而编写，不用于生产代码 — 的存在而获益。您不需要提前创建测试库，可以到时候再添加。例如，假定您编写了一些修改或检查系统状态的测试代码 — 只需将这些代码从测试类中取出，并将其转移到测试库中以供将来使用。

应用最佳实践。 您可以使用与生产代码所遵循规则迥异的规则来编写要加入测试库的代码：

• 测试库代码不需要严格检查先决条件（例如空指针），这是因为测试中的失败将捕获这种问题。
• 测试库代码不需要抛出检查到的异常。任何被捕获的检查到的异常都可以只作为运行时异常再次抛出，并且可以由测试框架捕获。
• 通常使用静态方法更合适。这突出了创建测试库的目标。生产代码将使用通过接口提供的对象实例来使灵活性和代码重用最大化。另一方面，您的测试实用工具经常需要执行非常具体的任务并与测试环境本身紧密耦合。正确使用静态方法会使您减少测试支持代码的数量，这是因为您甚至不需要担心对象的实例化。

下面代码显示了使用中的示例应用程序测试库：

public void testPersonsWithIdLookup() 
{

	List results = dao.listPersons("Phil", null);
	assertNotNull(results);
	assertEquals(2, results.size());

	for (Iterator iter = results.iterator(); iter.hasNext();) 
	{
		Person person = (Person) iter.next();
		assertNotNull(person.getId());
		assertEquals("Phil", PersonUtils.getFirstName(person.getId(),
				connection));
		doCommonAsserts(person);
	}
}

第一次使用显示了如何获取数据库连接。您将获取连接的确切机制从测试中隐藏起来了。ConnectionUtils 用于获取连接的机制 — DriverManager 的静态方法而不是 JDBC DataSource 或连接池实现 — 是专门用于测试环境的。第二次使用显示了如何能够在测试库中添加应用程序特有的功能。

PersonUtils.getFirstName() 只是一个使您能够通过最少的击键次数从数据库中检索一条信息的方便方法。测试库中这种类型的功能越多，您对测试环境可以施加的控制就越大。

试一试。使用 Applications Navigator 视图仔细研读 co.uk.realsolve.databasetest.library 程序包及其子程序包，获得测试库方法的示例。通过选择方法名称然后输入 CTRL + ALT-U 查看任意方法的用法。

最佳实践 7：有效地隔离测试

隔离测试以便一个测试的错误或失败不会影响其他测试或使它们无法成功执行。任何数据库测试的运行都需要预先将系统设置为某个稳定的已知状态。您的测试环境应使您能够自由地以任意顺序运行任意测试集。如果一个测试更改了系统但没有撤销这些更改，那么除非您考虑了这种可能性，否则所有后续测试都将以失败告终。因此，需要隔离测试以消除相互的影响，从而防止这种情况的发生。

应用最佳实践。 有三种简化测试隔离的方法：

• 撤销在测试执行前或期间所作的所有更改。
• 在执行任何测试之前清除所有测试状态。
• 回滚（而非提交）测试期间所作的更改。

前两种方法是关于如何管理测试固件、封装已知系统状态的对象和测试启动时的运行时环境。通过第一种方法，您一般可以使用 JUnit tearDown() 方法来重置系统状态。这种方法存在一些缺点。首先，您需要编写拆卸代码，它本身如果不经过严格测试可能会包含错误。由于这些错误会以不可预测和难以追踪的方式影响后续测试，因此这种错误极难发现。

第二个方法涉及到在测试执行之前清除所有的测试状态。该方法对不与现有数据库交互的新应用程序而言肯定特别合适。以下示例显示了如何将这种方法应用到我们测试类的 setUp() 方法中：

protected void setUp() throws Exception 
{
	super.setUp();
	SqlPlusRunner.runSQLPlusFile("truncate_data.sql");
	assertEquals(0, SqlPlusRunner.runSQLPlusFile("persons_data.sql"));

	//complete setup of the fixture by initializing DAO with connection to database
	dao = new PersonDAOImpl();
	dao.setConnection(connection = ConnectionUtils.getConnection());
}

注意截除数据脚本如何在加载测试数据之前运行。这就用非常少的努力保证了测试将在数据库处于可预测状态的前提下开始。除了这个明显的好处之外，它有以下缺点：

• 各个测试类可以使用它自己的测试数据，这增加了真正的测试数据文件爆炸的可能性。如果测试操作需要处理测试与测试间变化不大的复杂数据集，那么一定程度的测试数据共享会很有好处，即使这意味着偶尔需要使用 tearDown() 方法来重置状态。
• 有时只是不可能在每次运行之前都重置数据状态。如果您在开发一个使用了由外部 DBA 小组管理的共享旧式数据库实例的应用程序，那么这可能就是这种情况了。

第三种方法涉及到回滚而非提交在测试运行期间所作的更改。这会非常有效，其原因有两个：

• 现代数据库（如 Oracle 数据库）提供了出色的事务支持，以便您可以仅使用 Connection.rollback(); 轻松撤销当前事务所做的所有工作。
• 在 Oracle 数据库事务期间所作的所有更改在事务内均可见。换句话说，如果您要继续执行 Connection.commit() 调用，那么查询要提交的任何更改将非常容易。唯一的限制是您需要使用相同的 Connection 实例来查询在事务期间所作的查询更改。该策略不适于需要在执行期间提交多次的操作。

试一试。仔细查看 TestListPersons 类中的 setup() 的实现，其中将在每次测试之前加载测试数据。将类作为 Java 应用程序运行。在 Oracle JDeveloper 的输出日志中，您将看到所执行的 SQL*Plus 命令（如图 3 所示）。

图 3：作为 Java 应用程序运行的 TestListPersons 的控制台输出

最佳实践 8：分割测试套件

将您的整个测试集分割为一些个别的子套件，以使您的测试环境更加易于管理并共享代码和进程。

如果您在测试一个大型数据库驱动的系统，您可能要进行成百上千或者甚至成千上万个数据库测试。您需要将测试分割为个别的子套件以使测试环境易于管理。您可以从各种方案中进行选择来有效地将测试分组：

• 将依赖于相同的基础测试数据集的测试分组
• 为只读的测试与读/写测试创建单独的套件。
• 为细粒度测试（可能直接利用 SQL 和 PreparedStatements 执行）与在 DAO 实现层执行的粗粒度测试创建单独的套件。
• 根据应用程序的功能范围分离测试。

通过有效地分割测试，您可以创建一个更加一致和易管理的测试环境。您将有更多的机会共享测试代码、测试数据和常见的设置和拆卸操作。

应用最佳实践。JUnit suite() 方法提供了一种非常方便的分割测试套件的机制。我们的示例应用程序将整个测试套件分割为三个子套件：

public class AllTests extends TestCase 
{

	public static void main(String[] args)
	{
		junit.textui.TestRunner.run(suite());
	}

	public static Test suite() 
	{
		TestSuite suite = new TestSuite();
		suite.addTest(SqlPlusBasedTests.suite());
		suite.addTest(DbUnitTests.suite());
		suite.addTest(TestsOfTests.suite());
		return suite;
	}
}

基于 SQL*Plus 的测试从使用 DbUnit 的测试中分离出来，并为本文创建了一个用于小型框架的测试套件。各个套件的设置和拆卸操作都包含在相关的 suite() 方法内。例如，SqlPlusBasedTest 实现了以下 suite() 方法：

public static Test suite()
{

	TestSuite suite = new TestSuite();
	suite.addTestSuite(TestListPersons.class);
	... add other tests

	//use test wrapper to drop and re-create tables
	TestSetup wrapper = new TestSetup(suite)
	{
		protected void setUp()
                {
			SqlPlusRunner.runSQLPlusFile("drop_tables.sql");
			System.out.println("Setting up all tables ...");
			SqlPlusRunner.runSQLPlusFile("create_tables.sql");
		}

		protected void tearDown()
		{
			//no implementation required
		}
	};
	return wrapper;
}

TestSetup 绕接器允许套件中的所有测试共用设置，在这种情况下将删除数据库表然后重新创建它们。

试一试。您可以通过从 Oracle JDeveloper 中打开 Java 源文件，右键单击，然后选择 Run 来运行任何测试类。安装 JUnit 后，您可以将类作为 JUnit 测试来运行。JDeveloper 将显示一个 JUnit 输出窗口，该窗口显示了测试运行的进度，并指示哪些测试失败或导致错误。图 4 显示了 SqlPlusBasedTests.java 在一些测试方法被修改为失败之后的输出。

图 4：失败测试的示例输出

最佳实践 9：使用适当的框架（如 DbUnit）简化过程。

诸如 DbUnit 的框架可以简化数据库单元测试的各个方面。它一定程度上扩展了该最佳实践的定义，并建议作为一种最佳实践，您应当使用 DbUnit。这是因为 DbUnit 不是一种最佳实践，而是一种帮助简化数据库应用程序测试的 JUnit 库扩展。使用 DbUnit 的优点是它使得应用本文介绍的许多最佳实践变得非常容易。

应用最佳实践。要应用该框架，您需要对主要的 DbUnit 类和接口有基本的了解。基于 DbUnit 的测试的主要接口是 IDataSet。您可以认为 IDataSet 代表一个或多个表的数据。可以将数据库模式的全部内容表示为单个 IDataSet 实例。这些表本身由 Itable 实例来表示。

IDataSet 的实现有很多，每一个都对应一个不同的数据源或加载机制。最常用的三种 IDataSet 实现为：

• FlatXmlDataSet：数据的简单平面文件 XML 表示
• QueryDataSet：用 SQL 查询获得的数据
• DatabaseDataSet：数据库表本身内容的一种表示

下面是两种真正有用的 DbUnit 特性：

• 您可以从一种 IDataSet 实现中读取数据，并写入另一种实现。这使您能够（比如说）从平面 XML 文件中填充数据库，或者用数据库表中的数据或查询检索得到的数据创建平面 XML 文件。这使您能够非常容易地管理数据库测试环境。
• 您可以比较包含在不同数据集中的数据的内容。利用这种功能，您可以比较数据库表的内容或利用纯文本 XML 文件的内容进行查询。这是一种强大的特性，因为它允许非常精确的测试，而不必编写很多代码来支持它。

以下示例显示了工作中的 IDataSet 比较特性：

public void testListPersons() throws Exception 
{
	FlatXmlDataSet loadedDataSet = new FlatXmlDataSet(DbUnitUtils
			.getDbUnitFile("persons_data.xml"));
	QueryDataSet queryDataSet = new QueryDataSet(getConnection());
	queryDataSet.addTable("PERSON", "SELECT * FROM PERSON ORDER BY ID");
	Assertion.assertEquals(loadedDataSet, queryDataSet);
}

该功能允许您外化断言数据（在上面的示例中，断言数据被包含在 XML 文件中）。它还在测试更新操作的结果时非常有用；您可以使用查询来从比较数据中排除不相关的表和行。