本文摘自：http://www.ibm.com/developerworks/cn/java/j-junit4.html
JUnit 是 Java? 语言事实上的 标准单元测试库。JUnit 4 是该库三年以来最具里程碑意义的一次发布。它的新特性主要是通过采用 Java 5 中的标记（annotation）而不是利用子类、反射或命名机制来识别测试，从而简化测试。在本文中，执着的代码测试人员 Elliotte Harold 以 JUnit 4 为例，详细介绍了如何在自己的工作中使用这个新框架。注意，本文假设读者具有 JUnit 的使用经验。
JUnit 由 Kent Beck 和 Erich Gamma 开发，几乎毫无疑问是迄今所开发的最重要的第三方 Java 库。正如 Martin Fowler 所说，“在软件开发领域，从来就没有如此少的代码起到了如此重要的作用”。JUnit 引导并促进了测试的盛行。由于 JUnit，Java 代码变得更健壮，更可靠，bug 也比以前更少。JUnit（它本身的灵感来自 Smalltalk 的 SUnit）衍生了许多 xUnit 工具，将单元测试的优势应用于各种语言。nUnit (.NET)、pyUnit (Python)、CppUnit (C++)、dUnit (Delphi) 以及其他工具，影响了各种平台和语言上的程序员的测试工作。
然而，JUnit 仅仅是一个工具而已。真正的优势来自于 JUnit 所采用的思想和技术，而不是框架本身。单元测试、测试先行的编程和测试驱动的开发并非都要在 JUnit 中实现，任何比较 GUI 的编程都必须用 Swing 来完成。JUnit 本身的最后一次更新差不多是三年以前了。尽管它被证明比大多数框架更健壮、更持久，但是也发现了 bug；而更重要的是，Java 不断在发展。Java 语言现在支持泛型、枚举、可变长度参数列表和注释，这些特性为可重用的框架设计带来了新的可能。
JUnit 的停滞不前并没有被那些想要废弃它的程序员所打败。挑战者包括 Bill Venners 的 Artima SuiteRunner 以及 Cedric Beust 的 TestNG 等。这些库有一些可圈可点的特性，但是都没有达到 JUnit 的知名度和市场占有份额。它们都没有在诸如 Ant、Maven 或 Eclipse 之类的产品中具有广泛的开箱即用支持。所以 Beck 和 Gamma 着手开发了一个新版本的 JUnit，它利用 Java 5 的新特性（尤其是注释）的优势，使得单元测试比起用最初的 JUnit 来说更加简单。用 Beck 的话来说，“JUnit 4 的主题是通过进一步简化 JUnit，鼓励更多的开发人员编写更多的测试。”JUnit 4 尽管保持了与现有 JUnit 3.8 测试套件的向后兼容，但是它仍然承诺是自 JUnit 1.0 以来 Java 单元测试方面最重大的改进。
注意：该框架的改进是相当前沿的。尽管 JUnit 4 的大轮廓很清晰，但是其细节仍然可以改变。这意味着本文是对 JUnit 4 抢先看，而不是它的最终效果。
测试方法
以前所有版本的 JUnit 都使用命名约定和反射来定位测试。例如，下面的代码测试 1+1 等于 2：
import junit.framework.TestCase;
public class AdditionTest extends TestCase 
{
private int x = 1;
private int y = 1;
public void testAddition() {
int z = x + y;
assertEquals(2, z);
}
} 而在 JUnit 4 中，测试是由 @Test 注释来识别的，如下所示：
import org.junit.Test;
import junit.framework.TestCase;
public class AdditionTest extends TestCase {
private int x = 1;
private int y = 1;
@Test public void testAddition() {
int z = x + y;
assertEquals(2, z);
}
}
使用注释的优点是不再需要将所有的方法命名为 testFoo()、testBar()，等等。例如，下面的方法也可以工作：
import org.junit.Test;
import junit.framework.TestCase;
public class AdditionTest extends TestCase {
private int x = 1;
private int y = 1;
@Test public void additionTest() {
int z = x + y;
assertEquals(2, z);
}
}
下面这个方法也同样能够工作：
import org.junit.Test;
import junit.framework.TestCase;
public class AdditionTest extends TestCase {
private int x = 1;
private int y = 1;
@Test public void addition() {
int z = x + y;
assertEquals(2, z);
}
}
这允许您遵循最适合您的应用程序的命名约定。例如，我介绍的一些例子采用的约定是，测试类对其测试方法使用与被测试的类相同的名称。例如，List.contains() 由 ListTest.contains() 测试，List.add() 由 ListTest.addAll() 测试，等等。
TestCase 类仍然可以工作，但是您不再需要扩展它了。只要您用 @Test 来注释测试方法，就可以将测试方法放到任何类中。但是您需要导入 junit.Assert 类以访问各种 assert 方法，如下所示：
import org.junit.Assert;
public class AdditionTest {
private int x = 1;
private int y = 1;
@Test public void addition() {
int z = x + y;
Assert.assertEquals(2, z);
}
}
您也可以使用 JDK 5 中新特性（static import），使得与以前版本一样简单：
import static org.junit.Assert.assertEquals;
public class AdditionTest {
private int x = 1;
private int y = 1;
@Test public void addition() {
int z = x + y;
assertEquals(2, z);
}
}
这种方法使得测试受保护的方法非常容易，因为测试案例类现在可以扩展包含受保护方法的类了。
SetUp 和 TearDown
JUnit 3 测试运行程序（test runner）会在运行每个测试之前自动调用 setUp() 方法。该方法一般会初始化字段，打开日志记录，重置环境变量，等等。例如，下面是摘自 XOM 的 XSLTransformTest 中的 setUp() 方法：
protected void setUp() {
System.setErr(new PrintStream(new ByteArrayOutputStream()));
inputDir = new File("data");
inputDir = new File(inputDir, "xslt");
inputDir = new File(inputDir, "input");
}
在 JUnit 4 中，您仍然可以在每个测试方法运行之前初始化字段和配置环境。然而，完成这些操作的方法不再需要叫做 setUp()，只要用 @Before 注释来指示即可，如下所示：
@Before protected void initialize() {
System.setErr(new PrintStream(new ByteArrayOutputStream()));
inputDir = new File("data");
inputDir = new File(inputDir, "xslt");
inputDir = new File(inputDir, "input");
}
甚至可以用 @Before 来注释多个方法，这些方法都在每个测试之前运行：
@Before protected void findTestDataDirectory() {
inputDir = new File("data");
inputDir = new File(inputDir, "xslt");
inputDir = new File(inputDir, "input");
}
@Before protected void redirectStderr() {
System.setErr(new PrintStream(new ByteArrayOutputStream()));
}
清除方法与此类似。在 JUnit 3 中，您使用 tearDown() 方法，该方法类似于我在 XOM 中为消耗大量内存的测试所使用的方法：
protected void tearDown() {
doc = null;
System.gc();
}
对于 JUnit 4，我可以给它取一个更自然的名称，并用 @After 注释它：
@After protected void disposeDocument() {
doc = null;
System.gc();
}
与 @Before 一样，也可以用 @After 来注释多个清除方法，这些方法都在每个测试之后运行。
最后，您不再需要在超类中显式调用初始化和清除方法，只要它们不被覆盖即可，测试运行程序将根据需要自动为您调用这些方法。超类中的 @Before 方法在子类中的 @Before 方法之前被调用（这反映了构造函数调用的顺序）。@After 方法以反方向运行：子类中的方法在超类中的方法之前被调用。否则，多个 @Before 或 @After 方法的相对顺序就得不到保证。
套件范围的初始化
JUnit 4 也引入了一个 JUnit 3 中没有的新特性：类范围的 setUp() 和 tearDown() 方法。任何用 @BeforeClass 注释的方法都将在该类中的测试方法运行之前刚好运行一次，而任何用 @AfterClass 注释的方法都将在该类中的所有测试都运行之后刚好运行一次。
例如，假设类中的每个测试都使用一个数据库连接、一个网络连接、一个非常大的数据结构，或者还有一些对于初始化和事情安排来说比较昂贵的其他资源。不要在每个测试之前都重新创建它，您可以创建它一次，并还原它一次。该方法将使得有些测试案例运行起来快得多。例如，当我测试调用第三方库的代码中的错误处理时，我通常喜欢在测试开始之前重定向 System.err，以便输出不被预期的错误消息打乱。然后我在测试结束后还原它，如下所示：
// This class tests a lot of error conditions, which
// Xalan annoyingly logs to System.err. This hides System.err
// before each test and restores it after each test.
private PrintStream systemErr;
@BeforeClass protected void redirectStderr() {
systemErr = System.err; // Hold on to the original value
System.setErr(new PrintStream(new ByteArrayOutputStream()));
}
@AfterClass protected void tearDown() {
// restore the original value
System.setErr(systemErr);
}
没有必要在每个测试之前和之后都这样做。但是一定要小心对待这个特性。它有可能会违反测试的独立性，并引入非预期的混乱。如果一个测试在某种程度上改变了 @BeforeClass 所初始化的一个对象，那么它有可能会影响其他测试的结果。它有可能在测试套件中引入顺序依赖，并隐藏 bug。与任何优化一样，只在剖析和基准测试证明您具有实际的问题之后才实现这一点。这就是说，我看到了不止一个测试套件运行时间如此之长，以至不能像它所需要的那样经常运行，尤其是那些需要建立很多网络和数据库连接的测试。（例如，LimeWire 测试套件运行时间超过两小时。）要加快这些测试套件，以便程序员可以更加经常地运行它们，您可以做的就是减少 bug。
测试异常
异常测试是 JUnit 4 中的最大改进。旧式的异常测试是在抛出异常的代码中放入 try 块，然后在 try 块的末尾加入一个 fail() 语句。例如，该方法测试被零除抛出一个 ArithmeticException：
public void testDivisionByZero() {
try {
int n = 2 / 0;
fail("Divided by zero!");
}
catch (ArithmeticException success) {
assertNotNull(success.getMessage());
}
}
该方法不仅难看，而且试图挑战代码覆盖工具，因为不管测试是通过还是失败，总有一些代码不被执行。在 JUnit 4 中，您现在可以编写抛出异常的代码，并使用注释来声明该异常是预期的：
@Test(expected=ArithmeticException.class)
public void divideByZero() {
int n = 2 / 0;
}
如果该异常没有抛出（或者抛出了一个不同的异常），那么测试就将失败。但是如果您想要测试异常的详细消息或其他属性，则仍然需要使用旧式的 try-catch 样式。
被忽略的测试
也许您有一个测试运行的时间非常地长。不是说这个测试应该运行得更快，而是说它所做的工作从根本上比较复杂或缓慢。需要访问远程网络服务器的测试通常都属于这一类。如果您不在做可能会中断该类测试的事情，那么您可能想要跳过运行时间长的测试方法，以缩短编译-测试-调试周期。或者也许是一个因为超出您的控制范围的原因而失败的测试。例如，W3C XInclude 测试套件测试 Java 还不支持的一些 Unicode 编码的自动识别。不必老是被迫盯住那些红色波浪线，这类测试可以被注释为 @Ignore，如下所示：
// Java doesn't yet support
// the UTF-32BE and UTF32LE encodings
@Ignore public void testUTF32BE()
throws ParsingException, IOException, XIncludeException {
File input = new File(
"data/xinclude/input/UTF32BE.xml"
);
Document doc = builder.build(input);
Document result = XIncluder.resolve(doc);
Document expectedResult = builder.build(
new File(outputDir, "UTF32BE.xml")
);
assertEquals(expectedResult, result);
}
测试运行程序将不运行这些测试，但是它会指出这些测试被跳过了。例如，当使用文本界面时，会输出一个“I”（代表 ignore），而不是为通过的测试输出所经历的时间，也不是为失败的测试输出“E”：
$ java -classpath .:junit.jar org.junit.runner.JUnitCore
nu.xom.tests.XIncludeTest
JUnit version 4.0rc1
..I..
Time: 1.149
OK (7 tests)
但是一定要小心。最初编写这些测试可能有一定的原因。如果永远忽略这些测试，那么它们期望测试的代码可能会中断，并且这样的中断可能不能被检测到。忽略测试只是一个权宜之计，不是任何问题的真正解决方案。
时间测试
测试性能是单元测试最为痛苦的方面之一。JUnit 4 没有完全解决这个问题，但是它对这个问题有所帮助。测试可以用一个超时参数来注释。如果测试运行的时间超过指定的毫秒数，则测试失败。例如，如果测试花费超过半秒时间去查找以前设置的一个文档中的所有元素，那么该测试失败：
@Test(timeout=500) public void retrieveAllElementsInDocument() {
doc.query("//*");
}
除了简单的基准测试之外，时间测试也对网络测试很有用。在一个测试试图连接到的远程主机或数据库宕机或变慢时，您可以忽略该测试，以便不阻塞所有其他的测试。好的测试套件执行得足够快，以至程序员可以在每个测试发生重大变化之后运行这些测试，有可能一天运行几十次。设置一个超时使得这一点更加可行。例如，如果解析 http://www.ibiblio.org/xml 花费了超过 2 秒，那么下面的测试就会超时：
@Test(timeout=2000)
public void remoteBaseRelativeResolutionWithDirectory()
throws IOException, ParsingException {
builder.build("http://www.ibiblio.org/xml");
}
新的断言
JUnit 4 为比较数组添加了两个 assert() 方法：
public static void assertEquals(Object[] expected, Object[] actual)
public static void assertEquals(String message, Object[] expected,
Object[] actual)
这两个方法以最直接的方式比较数组：如果数组长度相同，且每个对应的元素相同，则两个数组相等，否则不相等。数组为空的情况也作了考虑。
需要补充的地方
JUnit 4 基本上是一个新框架，而不是旧框架的升级版本。JUnit 3 开发人员可能会找到一些原来没有的特性。
最明显的删节就是 GUI 测试运行程序。如果您想在测试通过时看到赏心悦目的绿色波浪线，或者在测试失败时看到令人焦虑的红色波浪线，那么您需要一个具有集成 JUnit 支持的 IDE，比如 Eclipse。不管是 Swing 还是 AWT 测试运行程序都不会被升级或捆绑到 JUnit 4 中。
下一个惊喜是，失败（assert 方法检测到的预期的错误）与错误（异常指出的非预期的错误）之间不再有任何差别。尽管 JUnit 3 测试运行程序仍然可以区别这些情况，而 JUnit 4 运行程序将不再能够区分。
最后，JUnit 4 没有 suite() 方法，这些方法用于从多个测试类构建一个测试套件。相反，可变长参数列表用于允许将不确定数量的测试传递给测试运行程序。
我对消除了 GUI 测试运行程序并不感到太高兴，但是其他更改似乎有可能增加 JUnit 的简单性。只要考虑有多少文档和 FAQ 当前专门用于解释这几点，然后考虑对于 JUnit 4，您不再需要解释这几点了。
编译和运行 JUnit 4
当前，还没有 JUnit 4 的库版本。如果您想要体验新的版本，那么您需要从 SourceForge 上的 CVS 知识库获取它。分支（branch）是“Version4”（参见 参考资料）。注意，很多的文档没有升级，仍然是指以旧式的 3.x 方式做事。Java 5 对于编译 JUnit 4 是必需的，因为 JUnit 4 大量用到注释、泛型以及 Java 5 语言级的其他特性。
自 JUnit 3 以来，从命令行运行测试的语法发生了一点变化。您现在使用 org.junit.runner.JUnitCore 类：
$ java -classpath .:junit.jar org.junit.runner.JUnitCore
TestA TestB TestC
JUnit version 4.0rc1
Time: 0.003
OK (0 tests)
兼容性
Beck 和 Gamma 努力维持向前和向后兼容。JUnit 4 测试运行程序可以运行 JUnit 3 测试，不用做任何更改。只要将您想要运行的每个测试的全限定类名传递给测试运行程序，就像针对 JUnit 4 测试一样。运行程序足够智能，可以分辨出哪个测试类依赖于哪个版本的 JUnit，并适当地调用它。
向后兼容要困难一些，但是也可以在 JUnit 3 测试运行程序中运行 JUnit 4 测试。这一点很重要，所以诸如 Eclipse 之类具有集成 JUnit 支持的工具可以处理 JUnit 4，而不需要更新。为了使 JUnit 4 测试可以运行在 JUnit 3 环境中，可以将它们包装在 JUnit4TestAdapter 中。将下面的方法添加到您的 JUnit 4 测试类中应该就足够了：
public static junit.framework.Test suite() {
return new JUnit4TestAdapter(AssertionTest.class);
}
但是由于 Java 比较多变，所以 JUnit 4 一点都不向后兼容。JUnit 4 完全依赖于 Java 5 特性。对于 Java 1.4 或更早版本，它将不会编译或运行。
前景
JUnit 4 远没有结束。很多重要的方面没有提及，包括大部分的文档。我不推荐现在就将您的测试套件转换成注释和 JUnit 4。即使如此，开发仍在快速进行，并且 JUnit 4 前景非常看好。尽管 Java 2 程序员在可预见的未来仍然需要使用 JUnit 3.8，但是那些已经转移到 Java 5 的程序员则应该很快考虑使他们的测试套件适合于这个新的框架，以便匹配。
参考资料
学习
讨论
关于作者
Elliotte Rusty Harold 出生在新奥尔良，现在，他还定期回老家喝一碗美味的秋葵汤。不过目前他与妻子 Beth 定居在纽约临近布鲁克林的 Prospect Heights，与他们住在一起的还有猫咪 Charm（取自夸克）和 Marjorie（按照他岳母的名字）。他是 Polytechnic 大学计算机科学的副教授，讲授 Java 技术和面向对象编程。他的 Cafe au Lait 网站是 Internet 上最受欢迎的独立 Java 站点之一，姊妹站点 Cafe con Leche 是最受欢迎的 XML 站点之一。他的著作包括 Effective XML 、 Processing XML with Java 、 Java Network Programming 和 The XML 1.1 Bible 。他目前在研究处理 XML 的 XOM API、Jaxen XPath 引擎和 Jester 测试覆盖工具。