setUp / tearDown(@ Before / @ After)为什么我们在JUnit中需要它们? [英] setUp/tearDown (@Before/@After) why we need them in JUnit?

查看:113
本文介绍了setUp / tearDown(@ Before / @ After)为什么我们在JUnit中需要它们?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我相信我们都知道setUp(@Before)会在任何测试方法执行之前执行,而tearDown(@After)将在测试方法之后执行。

I believe that we are all know that setUp (@Before) will execute before any test method and tearDown(@After) will execute after test method.

我们知道Junit将创建一个Test 每个测试方法的实例。

Also we know that Junit will create one instance of Test per test method.

我的问题是,我们可以将setUp方法内容移动到类Constructor并删除setUp方法吗?是否有任何特定的理由保留setUp方法?

my question is that can we just move setUp method content to class Constructor and remove setUp method? is there any specific reason to keep setUp method?

推荐答案

这(旧) JUnit最佳实践文章如下:


构造函数中设置测试用例不是个好主意。
考虑:

Do not use the test-case constructor to set up a test case

Setting up a test case in the constructor is not a good idea. Consider:

public class SomeTest extends TestCase
   public SomeTest (String testName) {
      super (testName);
      // Perform test set-up
   }
}

想象一下,在执行
设置时,设置代码会抛出
IllegalStateException 。作为回应,
JUnit将抛出
AssertionFailedError ,表示测试用例
不能实例化为
。以下是生成的堆栈跟踪
的示例:

Imagine that while performing the setup, the setup code throws an IllegalStateException. In response, JUnit would throw an AssertionFailedError, indicating that the test case could not be instantiated. Here is an example of the resulting stack trace:

junit.framework.AssertionFailedError: Cannot instantiate test case: test1   
    at junit.framework.Assert.fail(Assert.java:143)
    at junit.framework.TestSuite.runTest(TestSuite.java:178)
    at junit.framework.TestCase.runBare(TestCase.java:129)
    at junit.framework.TestResult.protect(TestResult.java:100)
    at junit.framework.TestResult.runProtected(TestResult.java:117)
    at junit.framework.TestResult.run(TestResult.java:103)
    at junit.framework.TestCase.run(TestCase.java:120)
    at junit.framework.TestSuite.run(TestSuite.java, Compiled Code)
    at junit.ui.TestRunner2.run(TestRunner.java:429)

这个堆栈跟踪证明相当于
没有信息;它只表示
测试用例不能实例化
。它没有详细说明
原始错误的
来源的位置或位置。缺乏信息使得
很难推断出异常的
基础原因。

This stack trace proves rather uninformative; it only indicates that the test case could not be instantiated. It doesn't detail the original error's location or place of origin. This lack of information makes it hard to deduce the exception's underlying cause.

而不是在
构造函数中设置数据,通过
覆盖 setUp()执行测试设置。在$ code> setUp()中抛出的任何异常
都会正确报告
。将此堆栈跟踪
与前面的示例进行比较:

Instead of setting up the data in the constructor, perform test setup by overriding setUp(). Any exception thrown within setUp() is reported correctly. Compare this stack trace with the previous example:

java.lang.IllegalStateException: Oops
    at bp.DTC.setUp(DTC.java:34) 
    at junit.framework.TestCase.runBare(TestCase.java:127)
    at junit.framework.TestResult.protect(TestResult.java:100)
    at junit.framework.TestResult.runProtected(TestResult.java:117)
    at junit.framework.TestResult.run(TestResult.java:103)
    ...

此堆栈跟踪更多信息
;它显示抛出了哪个异常
IllegalStateException )和
。这使得解释测试设置失败的原因变得更加容易

This stack trace is much more informative; it shows which exception was thrown (IllegalStateException) and from where. That makes it far easier to explain the test setup's failure.

这篇关于setUp / tearDown(@ Before / @ After)为什么我们在JUnit中需要它们?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆