注意Q?/strong>该框架的改进是相当前沿的。尽?JUnit 4 的大轮廓很清晎ͼ但是其细节仍然可以改变。这意味着本文是对 JUnit 4 抢先看,而不是它的最l效果?/p>
试Ҏ
以前所有版本的 JUnit 都用命名约定和反射来定位测试。例如,下面的代码测?1+1 {于 2Q?/p>
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
注释来识别的Q如下所C:
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()
?code>testBar()Q等{。例如,下面的方法也可以工作Q?/p>
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);
}
}
|
下面q个Ҏ也同栯够工作:
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);
}
}
|
q允许您遵@最适合您的应用E序的命名约定。例如,我介l的一些例子采用的U定是,试cd其测试方法用与被测试的cȝ同的名称。例如,List.contains()
?ListTest.contains()
试Q?code>List.add() ?ListTest.addAll()
试Q等{?/p>
TestCase
cM然可以工作,但是您不再需要扩展它了。只要您?@Test
来注释测试方法,可以将试Ҏ攑ֈMcM。但是您需要导?junit.Assert
cM讉K各种 assert ҎQ如下所C:
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 importQ,使得与以前版本一L单:
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);
}
}
|
q种Ҏ使得试受保护的Ҏ非常ҎQ因为测试案例类现在可以扩展包含受保护方法的cM?
SetUp ?TearDown
JUnit 3 试q行E序Qtest runnerQ会在运行每个测试之前自动调?setUp()
Ҏ。该Ҏ一般会初始化字D,打开日志记录Q重|环境变量,{等。例如,下面是摘?XOM ?XSLTransformTest
中的 setUp()
ҎQ?/p>
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 中,您仍然可以在每个试Ҏq行之前初始化字D和配置环境。然而,完成q些操作的方法不再需要叫?setUp()
Q只要用 @Before
注释来指C即可,如下所C:
@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
来注释多个方法,q些Ҏ都在每个试之前q行Q?
@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()));
}
|
清除Ҏ与此cM。在 JUnit 3 中,您?tearDown()
ҎQ该ҎcM于我?XOM 中ؓ消耗大量内存的试所使用的方法:
protected void tearDown() {
doc = null;
System.gc();
}
|
对于 JUnit 4Q我可以l它取一个更自然的名Uͼq用 @After
注释它:
@After protected void disposeDocument() {
doc = null;
System.gc();
}
|
?@Before
一P也可以用 @After
来注释多个清除方法,q些Ҏ都在每个试之后q行?/p>
最后,您不再需要在类中显式调用初始化和清除方法,只要它们不被覆盖卛_Q测试运行程序将Ҏ需要自动ؓ您调用这些方法。超cM?@Before
Ҏ在子cM?@Before
Ҏ之前被调用(q反映了构造函数调用的序Q?code>@After Ҏ以反方向q行Q子cM的方法在类中的Ҏ之前被调用。否则,多个 @Before
?@After
Ҏ的相寚w序就得不C证?/p>
套g范围的初始化
JUnit 4 也引入了一?JUnit 3 中没有的新特性:c范围的 setUp()
?tearDown()
Ҏ。Q何用 @BeforeClass
注释的方法都在该类中的试Ҏq行之前刚好q行一ơ,而Q何用 @AfterClass
注释的方法都在该类中的所有测试都q行之后刚好q行一ơ?/p>
例如Q假讄中的每个试都用一个数据库q接、一个网l连接、一个非常大的数据结构,或者还有一些对于初始化和事情安排来说比较昂늚其他资源。不要在每个试之前都重新创建它Q您可以创徏它一ơ,q还原它一ơ。该Ҏ得有些测试案例运行v来快得多。例如,当我试调用W三方库的代码中的错误处理时Q我通常喜欢在测试开始之前重定向 System.err
Q以便输Z被预期的错误消息打ؕ。然后我在测试结束后q原它,如下所C:
// 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);
}
|
没有必要在每个测试之前和之后都这样做。但是一定要心对待q个Ҏ。它有可能会q反试的独立性,q引入非预期的乱。如果一个测试在某种E度上改变了 @BeforeClass
所初始化的一个对象,那么它有可能会媄响其他测试的l果。它有可能在试套g中引入顺序依赖,q?bug。与M优化一P只在剖析和基准测试证明您h实际的问题之后才实现q一炏V这是_我看C不止一个测试套件运行时间如此之长,以至不能像它所需要的那样l常q行Q尤其是那些需要徏立很多网l和数据库连接的试。(例如QLimeWire 试套gq行旉过两小时。)要加快这些测试套Ӟ以便E序员可以更加经常地q行它们Q您可以做的是减少 bug?/p>
试异常
异常试?JUnit 4 中的最大改q。旧式的异常试是在抛出异常的代码中攑օ try
块,然后?try
块的末尾加入一?fail()
语句。例如,该方法测试被雉抛出一?ArithmeticException
Q?/p>
public void testDivisionByZero() {
try {
int n = 2 / 0;
fail("Divided by zero!");
}
catch (ArithmeticException success) {
assertNotNull(success.getMessage());
}
}
|
该方法不仅难看,而且试图挑战代码覆盖工具Q因Z测试是通过q是p|QL一些代码不被执行。在 JUnit 4 中,您现在可以编写抛出异常的代码Qƈ使用注释来声明该异常是预期的Q?
@Test(expected=ArithmeticException.class)
public void divideByZero() {
int n = 2 / 0;
}
|
如果该异常没有抛出(或者抛Z一个不同的异常Q,那么试将p|。但是如果您惌试异常的详l消息或其他属性,则仍焉要用旧式的 try-catch
样式?/p>
被忽略的试
也许您有一个测试运行的旉非常地长。不是说q个试应该q行得更快,而是说它所做的工作从根本上比较复杂或缓慢。需要访问远E网l服务器的测试通常都属于这一cR如果您不在做可能会中断该类试的事情,那么您可能想要蟩q运行时间长的测试方法,以羃短编?试-调试周期。或者也许是一个因出您的控制范围的原因而失败的试。例如,W3C XInclude 试套g试 Java q不支持的一?Unicode ~码的自动识别。不必老是被迫盯住那些U色波浪U,q类试可以被注释ؓ @Ignore
Q如下所C:
// 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);
}
|
试q行E序不q行q些试Q但是它会指些测试被跌了。例如,当用文本界面时Q会输出一?#8220;I”Q代?ignoreQ,而不是ؓ通过的测试输出所l历的时_也不是ؓp|的测试输?#8220;E”Q?/p>
$ java -classpath .:junit.jar org.junit.runner.JUnitCore
nu.xom.tests.XIncludeTest
JUnit version 4.0rc1
.....I..
Time: 1.149
OK (7 tests)
|
但是一定要心。最初编写这些测试可能有一定的原因。如果永q忽略这些测试,那么它们期望试的代码可能会中断Qƈ且这L中断可能不能被检到。忽略测试只是一个权宜之计,不是M问题的真正解x案?
旉试
试性能是单元测试最为痛苦的斚w之一。JUnit 4 没有完全解决q个问题Q但是它对这个问题有所帮助。测试可以用一个超时参数来注释。如果测试运行的旉过指定的毫U数Q则试p|。例如,如果试p过半秒旉L找以前设|的一个文档中的所有元素,那么该测试失败:
@Test(timeout=500) public void retrieveAllElementsInDocument() {
doc.query("http://*");
}
|
除了单的基准试之外Q时间测试也对网l测试很有用。在一个测试试图连接到的远E主机或数据库宕机或变慢Ӟ您可以忽略该试Q以便不d所有其他的试。好的测试套件执行得_快,以至E序员可以在每个试发生重大变化之后q行q些试Q有可能一天运行几十次。设|一个超时得这一Ҏ加可行。例如,如果解析 http://www.ibiblio.org/xml p了超q?2 U,那么下面的测试就会超Ӟ
@Test(timeout=2000)
public void remoteBaseRelativeResolutionWithDirectory()
throws IOException, ParsingException {
builder.build("http://www.ibiblio.org/xml");
}
|
新的断言
JUnit 4 为比较数l添加了两个 assert()
ҎQ?/p>
public static void assertEquals(Object[] expected, Object[] actual)
public static void assertEquals(String message, Object[] expected,
Object[] actual)
|
q两个方法以最直接的方式比较数l:如果数组长度相同Q且每个对应的元素相同,则两个数l相{,否则不相{。数lؓI的情况也作了考虑?
需要补充的地方
JUnit 4 基本上是一个新框架Q而不是旧框架的升U版本。JUnit 3 开发h员可能会扑ֈ一些原来没有的Ҏ?
最明显的删节就?GUI 试q行E序。如果您惛_试通过时看到赏心悦目的l色波浪U,或者在试p|时看Co人焦虑的U色波浪U,那么您需要一个具有集?JUnit 支持?IDEQ比?Eclipse。不是 Swing q是 AWT 试q行E序都不会被升或捆l到 JUnit 4 中?
下一个惊喜是Q失败(assert Ҏ到的预期的错误Q与错误Q异常指出的非预期的错误Q之间不再有M差别。尽?JUnit 3 试q行E序仍然可以区别q些情况Q?JUnit 4 q行E序不再能够区分?
最后,JUnit 4 没有 suite()
ҎQ这些方法用于从多个试cLZ个测试套件。相反,可变长参数列表用于允许将不确定数量的试传递给试q行E序?
我对消除?GUI 试q行E序q不感到太高_但是其他更改g有可能增?JUnit 的简单性。只要考虑有多文和 FAQ 当前专门用于解释q几点,然后考虑对于 JUnit 4Q您不再需要解释这几点了?
~译和运?JUnit 4
当前Q还没有 JUnit 4 的库版本。如果您惌体验新的版本Q那么您需要从 SourceForge 上的 CVS 知识库获取它。分支(branchQ是“Version4”Q参?参考资?/a>Q。注意,很多的文档没有升U,仍然是指以旧式的 3.x 方式做事。Java 5 对于~译 JUnit 4 是必需的,因ؓ JUnit 4 大量用到注释、泛型以?Java 5 语言U的其他Ҏ?
?JUnit 3 以来Q从命o行运行测试的语法发生了一点变化。您现在使用 org.junit.runner.JUnitCore
c:
$ java -classpath .:junit.jar org.junit.runner.JUnitCore
TestA TestB TestC...
JUnit version 4.0rc1
Time: 0.003
OK (0 tests)
|
兼容?/span>
Beck ?Gamma 努力l持向前和向后兼宏VJUnit 4 试q行E序可以q行 JUnit 3 试Q不用做M更改。只要将您想要运行的每个试的全限定cd传递给试q行E序Q就像针?JUnit 4 试一栗运行程序够智能,可以分L出哪个测试类依赖于哪个版本的 JUnitQƈ适当地调用它?
向后兼容要困难一些,但是也可以在 JUnit 3 试q行E序中运?JUnit 4 试。这一点很重要Q所以诸?Eclipse 之类h集成 JUnit 支持的工具可以处?JUnit 4Q而不需要更新。ؓ了 JUnit 4 试可以q行?JUnit 3 环境中,可以它们包装在 JUnit4TestAdapter
中。将下面的方法添加到您的 JUnit 4 试cM应该p够了Q?
public static junit.framework.Test suite() {
return new JUnit4TestAdapter(AssertionTest.class);
}
|
但是׃ Java 比较多变Q所?JUnit 4 一炚w不向后兼宏VJUnit 4 完全依赖?Java 5 Ҏ。对?Java 1.4 或更早版本,它将不会~译或运行?/p>
前景
JUnit 4 q没有结束。很多重要的斚w没有提及Q包括大部分的文。我不推荐现在就您的测试套件{换成注释?JUnit 4。即使如此,开发仍在快速进行,q且 JUnit 4 前景非常看好。尽?Java 2 E序员在可预见的未来仍然需要?JUnit 3.8Q但是那些已l{Ud Java 5 的程序员则应该很快考虑使他们的试套g适合于这个新的框Ӟ以便匚w?/p>

]]>