經驗四、在子類中調用父類的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 中定義的環境被初始化了。當然這也有例外，是基類可以處理任意的測試數據。
經驗五、不要硬性規定數據文件的路徑
我們經常需要從文件系統中讀取測試數據，看下面的代碼：
public void setUp () {
FileInputStream inp ("C:\TestData\dataSet1.dat");
...
}
這段代碼需要把測試數據文件dataSet1.dat 放在C:TestData，這是有問題的。
第一，C 盤可能沒有磁盤空間了測試人員不得不把數據文件放到其他路徑；
第二，可能需要在其他操作系統比如Linux 上執行這一測試。
所以，一個較好的替代方案是
public void setUp () {
FileInputStream inp ("dataSet1.dat");
...
}
但事實上這樣仍不是很好，因為這要求數據文件的路徑和測試執行的路徑必須是同一個，如果幾個不同的測試都這樣的話，那要把這些測試集合起來執行有些困難，我們不得不頻繁的改變當前路徑。為了解決這個問題，我們可以使用Class.getResource()或者Class.getResourceAsStream()，這樣我們可以把數據文件放在這個Class 的某個相對路徑上。數據文件應該盡可能和源代碼一起都放在配置管理系統上，但這樣一來如果我們采用上面的Resource 機制，我們需要做一件工作，是把數據文件從原來的位置－是源代碼的某個相對路徑，拷貝到編譯后的位置，也是class 文件的相應的相對路徑。這其實并不復雜，因為從class 的package 可以映射到java文件的所在路徑對于Linux或者Windows我們所要做的是把package中的. 用File.separatorChar 替代。
經驗六、把測試的代碼和被測的代碼放在同樣的目錄下
當我們把測試代碼和被測的代碼放在同一目錄下時，我們可以在編譯被測代碼的同時編譯測試代碼，從而確保兩者是同步更新的。事實上當前的普遍做法，是把單元測試視為Build 的一個環節。
經驗七、正確命名測試
把測試用例命名為TestClassUnderTest，比如如果被測的Class 是MessageLog，那么測試用例叫TestMessageLog，這樣做使得測試用例和被測的Class一一對應，而在測試用例中每個測試的method 可以命名為
testLoggingEmptyMessage()
testLoggingNullMessage()
testLoggingWarningMessage()
testLoggingErrorMessage()
同樣是為了說清楚測試的是什么。正確的命名可以幫助測試代碼的閱讀者了解每個測試的目的。
