JUnit4.5文档翻译2之Cookstour

JUnit A Cook's Tour
Note:this article is based on JUnit 3.8.x.

1.序言

在一篇早期的文章中（见Test Infected: Programmers Love Writing Tests, Java Report, July 1998, Volume 3, Number 7），我们描述了如何使用一个简单框架去编写可重复的测试。在本文，我们将揭开框架的面纱告诉你它是如何构成的。

我们小心翼翼研究了JUnit框架并且思考我们是如何构建它。我们找到很多不同难度的课程。在本文我们试着把他们都串起来写，发现这很难实现，但至少我们将向你展示这个软件中有价值的设计。

我们以框架的目标作为讨论的起点。这些目标将多次在框架描述的细节中重现，从中我们慢慢呈现这个框架的设计和实现。我们以多种形式的设计模式来描述它的设计（很惊讶吧），它的实现就像一个内容丰富的程序。我们以一些关于框架发展的想法作为本文的结束。

2.目标

JUnit的目标是什么？

首先，我们重新回到开发的假设情况。如果一个程序缺少自动测试，我们假定它不能运行。这个假设看来比那个盛行的假设更安全一些，那个假设说的是，如果一个开发者向我们保证，一个程序能运行，那么它现在并且永远能运行下去。

根据这个看法，开发者编写和调试代码时他们都没能做到，他们也必须编写测试以保证程序能运行。但不管怎样，每个人都很忙，他们要做的事情太多，他们不能为测试挤出足够的时间。我已经有太多的代码要写了，为何还要写测试代码呢？繁忙的项目经理这样回答我。

因此，我们第一个目标就是编写一个我们能看到希望火光的、能让开发者们真正去编写测试的框架。这个框架必须使用大家熟悉的工具，以致不用学什么新东西。它不需要多余的工作去编写一个新的测试。它还必须能消费重复。

如果你不得不去做所有的测试，你可能会使用调试器来调试语句。然而，这样的测试是不充分的。你的程序现在能运行，对于我来说并没有帮助，因为它不能让我确信，当我集成代码后它还能继续运行。它也不能让我确信，在你走后的未来五年它依然能运行。

因此，测试框架的第二个目标是创建的测试能长期保证它们的作用。除原始作者外的其他人，也必须能够去执行测试并理解测试结果。它可以联合各个作者的测试，并且一起运行它们时不用担心受到干扰。

最后，它必须能在创建新的测试时利用好已存在的测试代码。进行系统初始化的代价是昂贵的，这个框架必须能重新利用系统初始化去运行不同的测试。噢，这些还不够吗？

3.JUnit的设计

JUnit的设计将以一种首次使用的样式来展现（见"Patterns Generate Architectures", Kent Beck and Ralph Johnson, ECOOP 94）。这样做是为了说明一个系统的设计，开始时是没有模式的，接着运用一个又一个的模式直到系统的架构出来。我们将列出构建时解决的问题、总结实现的模式和展示这些模式是如何在JUnit中运用的。

3.1 开始-TestCase

首先，我们必须制造一个对象来表现TestCase这个基本概念。开发者通常都有测试用例的概念，但理解它们的方式有以下几种：

打印状态语句，调试器的调试语句和测试脚本。

如果想要很容易地操作测试代码，我们必须让它们变成对象。这样做可以实现一个目标，就是创建能长期保证它们作用的测试。同时，开发者经常会使用对象。把测试做成对象的决定，是因为能实现让编写测试更有吸引力（至少没有强迫性）这个目标。命令模式（见Gamma, E., et al. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1995）能很漂亮地满足我们的要求。根据这个意图引用，“把请求封装成对象，从而让你...”命令模式告诉我们，为操作创建一个对象并且赋予它一个执行的方法。TestCase类定义的代码为：

public abstract class TestCase implements Test { 
    … 
}

因为希望通过继承来重用这个类，我们申明它为"public abstract"。当前，我们忽略它实现了Test接口这个事实。因此，你可以认为TestCase是单独的类。

每一个TestCase创建时附带一个名称，那么如果测试失败了，你能识别出哪个测试是失败的。

public abstract class TestCase implements Test { 
    private final String fName;
    public TestCase(String name) { 
        fName= name; 
    }

    public abstract void run(); 
        … 
}

图1是TestCase的类图：


图1 使用命令模式的TestCase

3.2 实现-run()
下一个需要解决的问题是，为开发者放置初始化和测试代码找一个合适的地方。把TestCase申明为abstract是希望开发者能通过子类来重用TeseCase。然而，如果只是提供只有一个变量没有任何行为的超类，我们将不能实现首要目标，使测试更容易编写。

幸运地的是，我们为所有的测试提供了一个公用的结构：建立测试装置（fixture），在装置的基础上执行代码，校验结果和清除装置。这意味着，每一个测试都使用新的装置来执行，并且它的结果不会影响到另一个测试的结果。这样能满足最大化测试的价值的目标。

模板方法模式能很好地解决我们的问题。根据这个意图引用，“在一个操作中定义算法的骨架，延迟这些步骤在子类中实现。模板方法模式可以让子类重新定义算法中的某些步骤，而无需改变算法的结构。”这非常合适。我们希望开发者能够分开地思考，如何编写装置（set up and tear down）代码，如何编写测试代码。算法执行的顺序，对所有测试来说都是一样的，无论装置代码如何编写或者测试代码如何编写。

模板方法如下：

public void run() { 
    setUp(); 
    runTest(); 
    tearDown(); 
}

这些方法的默认实现是空的：

protected void runTest() { 
}
protected void setUp() { 
}
protected void tearDown() { 
}

由于setUp和tearDown可以被覆盖，并且只能让框架去调用，所以我们申明它们为protected。第二个场景在图2中描述：

图2 使用模板方法模式的TestCase.run()

3.3 记录结果-TestResult

在错综复杂的测试中执行一个TestCase，有谁还会关心它的结果？当然，你执行测试需要确保它们跑起来。当测试结束时，你需要的只是一个记录，能和不能运行的总结。

如果测试有同等机率的成功和失败，或者只跑一个测试，我们可以在TestCase对象中设置一个标志，并且当测试完成时去查看这个标志。然而，测试是很不对称的-它们通常能运行。因此，我们需要去记录失败的问题和成功的摘要。

Smalltalk最佳实践模式（见Beck, K. Smalltalk Best Practice Patterns, Prentice Hall, 1996）中有一个模式比较适用。它叫参数收集。它建议的是，当你需要在多个方法中收集结果时，你可以传给方法一个参数或者对象，用这个对象去收集这些方法的执行结果。我们创建一个新的Object，TestResult，去收集测试执行的结果。

public class TestResult extends Object { 
    protected int fRunTests;
    public TestResult() { 
       fRunTests= 0; 
    } 
}

这个TestResult的简单版本只能对执行的测试进行计数。为了使用它，我们需要给TestCase.run()方法传一个参数，通知TestResult测试正在执行：

public void run(TestResult result) { 
    result.startTest(this); 
    setUp(); 
    runTest(); 
    tearDown(); 
}

TestResult需要保持测试数目的状态：

public synchronized void startTest(Test test) { 
    fRunTests++; 
}

我们定义TesetResult的方法startTest是同步的，是为了当测试在不同线程上执行时，TestResult单例能够安全地收集执行结果。最后，我们想保留TestCase简单的对外接口，因此创建一个无参的run()来返回TestResult：

public TestResult run() { 
    TestResult result= createResult(); 
    run(result); 
    return result; 
}
protected TestResult createResult() { 
    return new TestResult(); 
}

图3展示了下一个设计模式。

图3 使用参数收集模式的TestResult

如果测试总是执行成功，我们就没必要编写它们了。测试失败会引人注意，特别是我们并不希望它们失败。此外，测试可以以我们期望的方式来失败，比如计算一个不正确的值，或者以一些明显的方式来失败，比如编写越界的数组。不管怎样即使测试失败了，我们也要继续执行其他的测试。

JUnit区分失败和错误。失败的可能性是可预料的，可用断言来检查。错误是不可预料的问题，比如ArrayIndexOutOfBoundsException。失败以AssertionFailedError为标志。为了使不可预料的错误区别于失败，我们用一个额外的语句（语句1）来捕抓失败。语句2捕抓其他的异常，确保测试能进行下去。

public void run(TestResult result) { 
    result.startTest(this); 
    setUp(); 
    try { 
        runTest(); 
    } 
    catch (AssertionFailedError e) { //1 
        result.addFailure(this, e); 
    }
    catch (Throwable e) { // 2 
        result.addError(this, e); 
    } 
    finally { 
        tearDown(); 
    } 
}

通过TestCase提供的断言方法可触发AssertionFailedError。JUnit提供了一组断言方法用于不同的目的。以下是最简单的一个：

protected void assertTrue(boolean condition) { 
    if (!condition) 
        throw new AssertionFailedError(); 
}

这不意味着由客户端（TestCase中的一个测试方法）来捕抓AssertionFailedError，而是由模板方法TestCase.run()来处理。因此我们从Error引申出AssertionFailedError。

public class AssertionFailedError extends Error { 
    public AssertionFailedError () {} 
}

在TestResult中收集错误的方法如下：

public synchronized void addError(Test test, Throwable t) { 
    fErrors.addElement(new TestFailure(test, t)); 
}
public synchronized void addFailure(Test test, Throwable t) { 
    fFailures.addElement(new TestFailure(test, t)); 
}

TestFailure是一个小型的框架内部辅助类，用来绑定失败的测试和稍后报告的异常。

public class TestFailure extends Object { 
    protected Test fFailedTest; 
    protected Throwable fThrownException; 
}

参数收集的权威形式要求我们给每个方法传递收集对象。如果我们按照这个建议，为了收集TestResult，每一个测试方法都需要传递一个参数。这造成了对方法签名的“污染（pollution）”。我们可以避免这种签名污染。测试用例方法可以抛出异常而不需要知道TestResult。以下是更新了的MoneyTest套件中的一个测试方法。它说明了测试方法如何不需要知道任何与TestResult有关：

public void testMoneyEquals() { 
    assertTrue(!f12CHF.equals(null)); 
    assertEquals(f12CHF, f12CHF); 
    assertEquals(f12CHF, new Money(12, "CHF")); 
    assertTrue(!f12CHF.equals(f14CHF)); 
}

JUnit配置了TestResult的不同实现。默认的实现可以对失败和错误的测试进行计数，并且收集执行的结果。TextTestResult收集结果并以文本方式显示它们。最后，UITestResult作为JUnit Test Runner的图形化版本，来增强测试状态的图形化。

TestResult是框架的一个扩展点。客户端可以定义自己定制的TestResult类，比如，HTMLTestResult以HTML文档的形式来显示结果。