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）關于數據庫表結構，我建議測試表中含有一個主鍵，我們在插入數據的時候，保證測試用例，測試用例程序，測試用例程序中的數據，這三者的編號一致起來。便于出現問題時，可以排除數據。