套件范围的初始化

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 样式。

JUnit 4.0体验(4)

被忽略的测试

也许您有一个测试运行的时间非常地长。不是说这个测试应该运行得更快，而是说它所做的工作从根本上比较复杂或缓慢。需要访问远程网络服务器的测试通 常都属于这一类。如果您不在做可能会中

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!