追求代码质量 - 可重复的系统测试

追求代码质量 - 可重复的系统测试2010-12-09 IBM Andrew Glover在本质上，像 JUnit 和 TestNG 一样的测试框架方便了可重复性测试的创建。由于这些框架利用了简单 Boolean 逻辑（以 assert 方法的形式）的可靠性，这使得无人为干预而运行测试成为可能。事实上，自动化是测试框架的主要优点之一 —— 我能够编写一个用于断言具体行为的相当复杂的测试，且一旦这些行为有所改变，框架就会报告一个人人都能明白的错误。

利用成熟的测试框架会带来框架可重复性的优点，这是显而易见的。但逻辑的可重复性却取决于您。例如，考虑创建用于验证 Web 应用程序的可重复测试的情况，一些 JUnit 扩展框架（如 JWebUnit 和 HttpUnit）在协助自动化的 Web 测试方面非常好用。但是，使测试的 plumbing 可重复则是开发人员的任务，而这在部署 Web 应用程序资源时很难进行。

实际的 JWebUnit 测试的构造过程相当简单，如清单 1 所示：

清单 1. 一个简单的 JWebUnit 测试

package test.come.acme.widget.Web;

import net.sourceforge.jwebunit.WebTester;
import junit.framework.TestCase;

public class WidgetCreationTest extends TestCase {
  private WebTester tester;

  protected void setUp（） throws Exception {
  this.tester = new WebTester（）;
  this.tester.getTestContext（）.
   setBaseUrl（"http://localhost:8080/widget/"）;
  }

  public void testWidgetCreation（） {
  this.tester.beginAt（"/CreateWidget.html"）;
  this.tester.setFormElement（"widget-id", "893-44"）;
  this.tester.setFormElement（"part-num", "rt45-3"）;

  this.tester.submit（）;
  this.tester.assertTextPresent（"893-44"）;
  this.tester.assertTextPresent（"successfully created."）;
  }
}

这个测试与一个 Web 应用程序通信，并试图创建一个基于该交互的小部件。该测试随后校验此部件是否被成功创建。读过本系列之前部分的读者们也许会注意到该测试的一个微妙的可重复性问题。您注意到了吗？如果这个测试用例连续运行两次会怎样呢？

由这个小部件实例（即，widget-id）的验证方面可以判断出，可以安全地做出这样的假设，即此应用程序中的数据库约束很可能会阻止创建一个已经存在的额外的小部件。由于缺少了一个在运行另一个测试前删除此测试用例的目标小部件的过程，如果再连续运行两次，这个测试用例非常有可能会失败。

幸运的是，如前面文章中所探讨的那样，有一个有助于数据库-依赖性（database-dependent）测试用例可重复性的机制 —— 即 DbUnit。