外部化测试数据

我们前面提到，创建测试用例的详细信息比较费力，并需要大量使用 SDO 编程 API。在我们的简单示例中，似乎不太大，但是对于带有数据对象的实际应用程序，难度可能会非常大，并会涉及许多嵌套层；为服务创建输入数据，然后验证结果的工作量会非常大。那么，从保存数据对象的 XML 表示形式的外部配置文件驱动测试似乎比较明智。在创建测试系列时，就变成了简单地复制和修改 XML 文件；实际上，经证明此方法比编写 SDO 代码更简单，出错率更低。

我们创建了一个框架，该框架支持此类测试用例的快速开发。在上面的设置说明中，为便于使用，我们提供了框架库。使用框架创建测试的过程为：

修改测试代码，以使用一组实用工具类
为配置文件创建目录层次结构
创建定义要执行的测试的配置文件
创建配置文件，以描述有效负载和预期的结果
创建数据对象 XML 文件。
A. 修改测试代码，以使用一组实用工具类

SCA 框架提供了管理测试数据加载的 ScaTestExecutor 实用工具类，它可以执行相应的测试。这样，测试方法的代码会变得非常简单：

public void testGoodPostCodeExternal() {
  ScaTestExecutor executor = new ScaTestExecutor(getClass(), getName());
  executor.executeServiceTest();
}
 
public void testBadPostCodeExternal() {
  ScaTestExecutor executor = new ScaTestExecutor(getClass(), getName());
  executor.executeServiceTest();
}

import com.ibm.swservices.sca.test.junit.ScaTestExecutor;

// ...
 

ScaTestExecutor 构造函数将测试类和测试的名称作为参数。（JUnit 框架提供了 getName() 方法，以便能够以编程方式访问测试方法的名称。）ScaTestExecutor 然后应用命名约定来确定配置文件的位置；接下来我们将描述该约定。

您可能认为测试方法的高重复性特性指示能够进行某种的重构。事实上，JUnit 框架在运行时允许我们动态创建测试套件，该套件源自可用的测试数据。不过，我们发现 Eclipse-JUnit 集成也不能与此类套件一起使用；无法快速重新运行单个失败的测试。因此，我们更希望创建所示的显式测试方法。

B. 为配置文件创建目录层次结构

我们希望在测试具有许多服务操作的实际模块时（特别是在测试 BPEL 进程时），将拥有许多要管理的测试。所以，如果具有许多相应的 XML 文件，则按某一方式组织这些文件非常重要。ScaTestExecutor 类实现了简单的命名约定，并为组织 XML 文件指定了目录层次结构。要构造此目录层次结构，请单击右键，然后选择 New => Other => Simple => Folder（图 14）。

图 14. 测试数据层次结构

层次结构的要素为：

• 测试数据目录层次结构根植于测试类包目录中，在我们的示例中，该目录为 org.djna.mailservice.test。这使得要下载的 XML 文件可以作为测试类类加载器的资源。

• 每个测试类都有一个目录，其名称源自测试类的名称，并附加前缀 -Data。

• 在该目录中，我们对每个测试方法都提供了一个目录，其名称完全匹配该方法名称。

• 在方法目录中有测试定义。它们是定义要执行的测试的 XML 文件，并具有扩展名 .tspec（稍后描述）。每个测试方法可以具有多个 .tspec 文件；它们将按字母顺序执行。