JUnit使用經(jīng)驗(yàn)(1)

原作：Andy Schneider Richard Dallaway 等
編譯：PMT 測試工作組

---

譯者注:
很多測試人員都有過編寫測試框架的經(jīng)歷，JUnit的出現(xiàn)避免了其中的大量重復(fù)勞動(dòng)。但如同其
他的工具一樣用得好和用得差的結(jié)果是截然不同的。我們編輯這樣一個(gè)JUnit的系列希望能夠幫助越
來越多的JUnit使用者用好JUnit。我們也希望讀者們能夠把自己的一些經(jīng)驗(yàn)所得和大家分享。

經(jīng)驗(yàn)一、不要在測試用例的構(gòu)造函數(shù)中做初始化
當(dāng)我們需要增加一個(gè)測試時(shí)，我們要書寫一個(gè)自己的測試用例，比如SomeTest。如果你喜歡在SomeTest的
構(gòu)造函數(shù)中做有關(guān)的初始化工作，這可不是個(gè)好習(xí)慣。如下例：
public class SomeTest extends TestCase{
public SomeTest(String testName){
super(testName);
//初始化代碼
}
}
一旦初始化代碼產(chǎn)生異常，比如IllegalStateException，JUnit隨之將產(chǎn)生一個(gè)AssertionFailedError，
并顯示類似下面的出錯(cuò)信息：
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 )
這一大堆出錯(cuò)信息只會(huì)讓人一頭霧水，我們只知道JUnit無法實(shí)例化某個(gè)測試用例，到底出了什么問題，在
哪兒出錯(cuò)了呢？不知道！
那么好的做法是怎樣呢？
答案是重載測試用例的setUp()方法進(jìn)行初始化。當(dāng)setUp()中的初始化代碼產(chǎn)生異常時(shí)我們得到的
是類似下面的出錯(cuò)信息：
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 行產(chǎn)生了IllegalStateException

經(jīng)驗(yàn)二、不要假定測試用例中測試的執(zhí)行次序
我們知道在一個(gè)JUnit 的測試用例類中可以包含多個(gè)測試，每個(gè)測試其實(shí)就是一個(gè)method。在下面的例子
中有兩個(gè)不同的測試，盡管testDoThisFirst()在位置上先于testDoThisSecond()，但我們不能就此假定
testDoThisFirst()會(huì)先執(zhí)行。
public class SomeTestCase extends TestCase{
public SomeTestCase(String testName){
super(testName);
}
public void testDoThisFirst(){
...
}
public void testDoThisSecond(){
}
}
由于JUnit 內(nèi)部使用一個(gè)Vector 來存儲(chǔ)所有的test，因此在不同的操作系統(tǒng)和Java 虛擬機(jī)上，test 的執(zhí)行
次序是不可預(yù)測的。
好的習(xí)慣是保持測試之間的獨(dú)立性，使得它們在任何次序下執(zhí)行的結(jié)果都是相同的。如果真得需要某些測試
按照特定的次序執(zhí)行，我們可以借助addTest 來實(shí)現(xiàn)。如下例：
public static Testsuite(){
suite.addTest(new SomeTestCase(“testDoThisFirst”;));
suite.addTest(new SomeTestCase(“testDoThisSecond”;));
return suite;
}
這樣我們可以確保JUnit先執(zhí)行testDoThisFirst()，然后執(zhí)行testDoThisSecond()。

經(jīng)驗(yàn)三、測試要避免人工干預(yù)
如果某段測試代碼需要人工干預(yù)，那至少有兩個(gè)不良后果：一則不能被包括在自動(dòng)測試中，比如夜間的回
歸測試；二則不能被重復(fù)執(zhí)行，例如數(shù)據(jù)刪除的測試不能做完刪除就萬事大吉，比較好的做法是自動(dòng)補(bǔ)上
刪除掉的數(shù)據(jù)。經(jīng)驗(yàn)二講的是不同的測試要避免相關(guān)性，而經(jīng)驗(yàn)三講的其實(shí)就是測試要避免自相關(guān)。