JUnit使用经验(1) -- 转自PMT杂志

JUnit使用经验(1)

原作：Andy Schneider Richard Dallaway 等
编译：PMT 测试工作组

---

译者注:
很多测试人员都有过编写测试框架的经历，JUnit的出现避免了其中的大量重复劳动。但如同其
他的工具一样用得好和用得差的结果是截然不同的。我们编辑这样一个JUnit的系列希望能够帮助越
来越多的JUnit使用者用好JUnit。我们也希望读者们能够把自己的一些经验所得和大家分享。

经验一、不要在测试用例的构造函数中做初始化
当我们需要增加一个测试时，我们要书写一个自己的测试用例，比如SomeTest。如果你喜欢在SomeTest的
构造函数中做有关的初始化工作，这可不是个好习惯。如下例：
public class SomeTest extends TestCase{
public SomeTest(String testName){
super(testName);
//初始化代码
}
}
一旦初始化代码产生异常，比如IllegalStateException，JUnit随之将产生一个AssertionFailedError，
并显示类似下面的出错信息：
j u n i t . f r a m e w o r k . A s s e r t i o n F a i l e d E r r o r : C a n n o t i n s t a n t i a t e t e s t c a s e : t e s t 1 a t
j u n i t . f r a m e w o r k . A s s e r t . f a i l ( A s s e r t . j a v a : 1 4 3 ) a t
j u n i t . f r a m e w o r k . T e s t S u i t e $ 1 . r u n T e s t ( T e s t S u i t e . j a v a : 1 7 8 ) a t
j u n i t . f r a m e w o r k . T e s t C a s e . r u n B a r e ( T e s t C a s e . j a v a : 1 2 9 ) a t
j u n i t . f r a m e w o r k . T e s t R e s u l t $ 1 . p r o t e c t ( T e s t R e s u l t . j a v a : 1 0 0 ) a t
j u n i t . f r a m e w o r k . T e s t R e s u l t . r u n P r o t e c t e d ( T e s t R e s u l t . j a v a : 1 1 7 ) a t
j u n i t . f r a m e w o r k . T e s t R e s u l t . r u n ( T e s t R e s u l t . j a v a : 1 0 3 ) a t
j u n i t . f r a m e w o r k . T e s t C a s e . r u n ( T e s t C a s e . j a v a : 1 2 0 ) a t
j u n i t . f r a m e w o r k . T e s t S u i t e . r u n ( T e s t S u i t e . j a v a , C o m p i l e d C o d e ) a t
j u n i t . u i . T e s t R u n n e r $ 1 2 . r u n ( T e s t R u n n e r . j a v a : 4 2 9 )
这一大堆出错信息只会让人一头雾水，我们只知道JUnit无法实例化某个测试用例，到底出了什么问题，在
哪儿出错了呢？不知道！
那么好的做法是怎样呢？
答案是重载测试用例的setUp()方法进行初始化。当setUp()中的初始化代码产生异常时我们得到的
是类似下面的出错信息：
j a v a . l a n g . I l l e g a l S t a t e E x c e p t i o n : O o p s a t b p . D T C . s e t U p ( D T C . j a v a : 3 4 ) a t
j u n i t . f r a m e w o r k . T e s t C a s e . r u n B a r e ( T e s t C a s e . j a v a : 1 2 7 ) a t
j u n i t . f r a m e w o r k . T e s t R e s u l t $ 1 . p r o t e c t ( T e s t R e s u l t . j a v a : 1 0 0 ) a t
j u n i t . f r a m e w o r k . T e s t R e s u l t . r u n P r o t e c t e d ( T e s t R e s u l t . j a v a : 1 1 7 ) a t
j u n i t . f r a m e w o r k . T e s t R e s u l t . r u n ( T e s t R e s u l t . j a v a : 1 0 3 )
...
显然这要清楚得多我们一下子就可以知道是在DTC.java 的第34 行产生了IllegalStateException

经验二、不要假定测试用例中测试的执行次序
我们知道在一个JUnit 的测试用例类中可以包含多个测试，每个测试其实就是一个method。在下面的例子
中有两个不同的测试，尽管testDoThisFirst()在位置上先于testDoThisSecond()，但我们不能就此假定
testDoThisFirst()会先执行。
public class SomeTestCase extends TestCase{
public SomeTestCase(String testName){
super(testName);
}
public void testDoThisFirst(){
...
}
public void testDoThisSecond(){
}
}
由于JUnit 内部使用一个Vector 来存储所有的test，因此在不同的操作系统和Java 虚拟机上，test 的执行
次序是不可预测的。
好的习惯是保持测试之间的独立性，使得它们在任何次序下执行的结果都是相同的。如果真得需要某些测试
按照特定的次序执行，我们可以借助addTest 来实现。如下例：
public static Testsuite(){
suite.addTest(new SomeTestCase(“testDoThisFirst”;));
suite.addTest(new SomeTestCase(“testDoThisSecond”;));
return suite;
}
这样我们可以确保JUnit先执行testDoThisFirst()，然后执行testDoThisSecond()。

经验三、测试要避免人工干预
如果某段测试代码需要人工干预，那至少有两个不良后果：一则不能被包括在自动测试中，比如夜间的回
归测试；二则不能被重复执行，例如数据删除的测试不能做完删除就万事大吉，比较好的做法是自动补上
删除掉的数据。经验二讲的是不同的测试要避免相关性，而经验三讲的其实就是测试要避免自相关。

原文转自：http://www.ltesting.net