原作：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()。
經驗三、測試要避免人工干預
如果某段測試代碼需要人工干預，那至少有兩個不良后果：一則不能被包括在自動測試中，比如夜間的回歸測試；二則不能被重復執行，例如數據刪除的測試不能做完刪除萬事大吉，比較好的做法是自動補上刪除掉的數據。經驗二講的是不同的測試要避免相關性，而經驗三講的其實是測試要避免自相關。
