經驗一、不要在測試用例的構造函數中做初始化
當我們需要增加一個測試時，我們要書寫一個自己的測試用例，比如sometest。如果你喜歡在sometest的
構造函數中做有關的初始化工作，這可不是個好習慣。如下例：
public class sometest extends testcase{
public sometest(string testname){
super(testname);
//初始化代碼
}
}
一旦初始化代碼產生異常，比如illegalstateexception，junit隨之將產生一個assertionfailederror，
并顯示類似下面的出錯信息：
junit . framework . assertionfailederror : cannotinstantiatetestcase : test1at
junit . framework . assert . fail ( assert . java : 143 ) at
junit . framework . testsuite$1 . runtest ( testsuite . java : 178 ) at
junit . framework . testcase . runbare ( testcase . java : 129 ) at
junit . framework . testresult$1 . protect ( testresult .java : 100 ) at
junit . framework . testresult . runprotected ( testresult. java: 117 ) at
junit . framework . testresult . run ( testresult. java : 103 ) at
junit . framework . testcase . run( testcase . java: 120 ) at
junit . framework . testsuite . run( testsuite . java ， compiledcode ) at
junit . ui . testrunner$12 . run (testrunner. java : 429 )
這一大堆出錯信息只會讓人一頭霧水，我們只知道junit無法實例化某個測試用例，到底出了什么問題，在
哪兒出錯了呢？不知道！
那么好的做法是怎樣呢？
答案是重載測試用例的setup()方法進行初始化。當setup()中的初始化代碼產生異常時我們得到的
是類似下面的出錯信息：
java . lang . illegalstateexception : oopsatbp . dtc . setup ( dtc .java: 34 ) at
junit . framework . testcase . runbare ( testcase .java: 127 ) at
junit . framework . testresult$ 1 . protect(testresult . java : 100 ) at
junit . framework . testresult . runprotected ( testresult . java: 117 ) at
junit . framework . testresult . run ( testresult .java : 103 )
...
顯然這要清楚得多我們一下子可以知道是在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()。
經驗三、測試要避免人工干預
如果某段測試代碼需要人工干預，那至少有兩個不良后果：一則不能被包括在自動測試中，比如夜間的回
歸測試；二則不能被重復執行，例如數據刪除的測試不能做完刪除萬事大吉，比較好的做法是自動補上
刪除掉的數據。經驗二講的是不同的測試要避免相關性，而經驗三講的其實是測試要避免自相關。
經驗四、在子類中調用父類的setup() 和teardown()讓我們看一看下面的代碼
public class sometestcase extends anothertestcase {
// a connection to a database
private database thedatabase;
public sometestcase (string testname) {
super (testname);
}
public void testfeaturex () {
...
}
public void setup () {
// clear out the database
thedatabase.clear ();
}
}
你發現其中的錯誤了嗎？setup()應該調用super.setup() 以確保anothertestcase 中定義的父類的環境被初
始化了。當然這也有例外，是基類可以處理任意的測試數據。
