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.z6688.com/
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
