1. 不要用TestCase的構造函數初始化Fixture，而要用
setUp()和tearDown()方法。
2. 不要依賴或假定測試運行的順序，因為JUnit利用
Vector保存測試方法。所以不同的平臺會按不同的
順序從Vector中取出測試方法。
3. 避免編寫有副作用的TestCase。例如：如果隨后的
測試依賴于某些特定的交易數據，就不要提交交易數
據。簡單的會滾就可以了。
? 對于我們來說，有時是必須要提交，以至于有副作用的。
? 例如：在執行“插入“后，數據庫顯然會多出一條數
據來。那么必須在隨后每個測試自己消除自己的副
作用。
??在這里，就是自己“再刪除剛插入的數據”。（這時候
需要考慮到這個善后的工作不能自己就不能有副作用，
? 刪除多了其他的數據）。
?
? 這里的副作用還指“影響到周圍環境”，因為我們現
在工作的人比較多，所以最好大家的測試服務器能夠
分開來，
?例如一個人一個Database實例（可以建得稍微小一
點）或者一個人一個數據庫，
? 注意將這些個人之間
有區別的內容用常量在每個人自己的所有程序中公
用。而不是分布在各個位置。
? 否則以后要改換測試
服務器，所有的程序都需要改動。
?
? 為了保證測試程序能夠很容易的到處執行，請保證
大家的數據庫服務器的測試數據全部一致。
?否則，
就不能做到很容易得拿到FJ也可以很容易的運行，
所以需要準備“測試數據集“。
包括：Schema ,table ，
stored procedure等數據庫對象的結構一致，
?還包
括數據庫的數據內容保持一致。
4. 當繼承一個測試類時，記得調用父類的setUp()和
tearDown()方法。
5. 將測試代碼和工作代碼放在一起，一邊同步編譯
和更新。（使用Ant中有支持junit的task.）
6. 測試類和測試方法應該有一致的命名方案。如在
工作類名前加上test從而形成測試類名。
可能這里我們需要改動，將函數名和我們的測試用
例的編號一致起來。
7. 確保測試與時間無關，不要依賴使用過期的數據
進行測試。導致在隨后的維護過程中很難重現測試。
8. 如果你編寫的軟件面向國際市場，編寫測試時要
考慮國際化的因素。不要僅用母語的Locale進行測試。
9. 盡可能地利用JUnit提供地assert/fail方法以及
異常處理的方法，可以使代碼更為簡潔。
?
這個內容有其關鍵，assert語句的好壞直接影響
到測試的正確性。
因為assert就是用于當前測試
項的正確性的。
10.測試要盡可能地小，執行速度快。
==========
1）將所有的數據庫的測試數據用ODBC程序自動
生成的。
用戶可以簡單的修改ConnectionString，
然后運行程序，就可以創建生成數據庫/數據庫
表/存儲結構，并且自動插入數據。
?
?? 2）為了保證多個測試人員的不干擾，建議分別
各自單獨使用自己的數據庫。否則會因為一個自
己的錯誤，影響別人的工作。
?
?? 3）在自己的程序中，所有涉及環境的內容都用
單獨放到一個類中，用static常量共享使用（這樣
就便于很容易的更換環境再進行測試，做到很容
易的移植測試環境）。
?
?? 4）關于數據庫表結構，我建議測試表中含有一
個主鍵，我們在插入數據的時候，保證測試用例，
測試用例程序，測試用例程序中的數據，這三者
的編號一致起來。便于出現問題時，可以排除數據。