1、測試數據/運行數據的互不影響
在做測試時，通常都需要生成測試數據，在測試運行完后又要進行測試數據的刪除工作，當測試和運行用的是同一個庫的情況下就很容易出現測試數據和運行數據互相影響的現象，這個時候在寫測試的時候就要特別的注意了，既不能讓運行數據影響了測試的結果，又不能讓測試數據影響到了運行數據。
通常來說，為了解決這個問題，會采用測試庫和運行庫分開的方式，采取這種方式的情況下就比較簡單了，不過有些時候還是挺麻煩的，畢竟要創建數據、刪除數據。
還有一種特殊的情況，例如一個這樣的項目：
項目已經上線運行了，這個時候做了一個新的流程，在部署了新的流程到運行環境后，通常需要在運行環境中測試一下，這個時候問題就出現了，測試數據和運行數據并行，這個時候就要充分的考慮測試數據和運行數據的互不影響。
當然，上面的項目的情況是一個比較特殊的情況，就像icecloud說的，項目規劃的好的話是會有測試環境和運行環境的不同的，測試環境需要和運行環境完全一致，在有新增的東西需要部署到運行環境時先在測試環境進行測試，測試沒問題后再通過升級腳本部署到運行環境中。
這些方法確實是可以解決測試數據/運行數據的互相影響的問題，不過覺得還是有些的麻煩，覺得如果有一個工具可以幫忙避免測試數據/運行數據的互相影響，同時又可以讓你在寫測試的時候很容易的創建測試數據，又不用擔心其他測試數據或運行數據對它造成影響，最后測試數據又可以安全的被清除，^_^，有個這樣的工具就好了.........
或者說大家在實際中碰到測試數據/運行數據并行的情況下會怎么辦呢..
2、單元測試
一直以來都實行TDD，不過發現我做單元測試的方法仍然不正確，盡管在測試的基本原則---"測試一定情況下單元的執行是否和預期一致"上是正確的，但進行單元測試的方法并不正確，就像robbin所說，我做的是集成測試，因為我做單元測試時會去把該單元依賴的其他的對象所需要的東西也去進行模擬，這樣說起來可能過于生澀了，舉個例子吧：
有一個服務類，該服務類依賴一個Dao類，通過Dao從數據庫中獲取相關的信息后進行處理，我以前做單元測試的做法就是首先產生出測試數據，由Dao先將測試數據進行持久，之后再通過調用服務類的方法去執行，"一定的情況"通常都是由測試數據來控制，這點沒什么不對，就是控制所測試的單元的輸入。
測試的基本原則都是檢查在一定的輸入的情況下輸出是否符合預期，作為單元測試而言上面的做法不正確的地方就是去產生測試數據并由Dao先持久，其實作為單元測試而言，只需要測試當前對象執行的正確性，也就是說它已經假設了它所依賴的其他的對象產生的結果，這樣的單元測試才是有意義的，而且也變得更容易寫了，之前我所采用的那種測試其實是集成測試....
這樣說了后其實就很容易理解單元測試了，仍然是上面的服務類，它的單元測試的寫法應該是去Mock出Dao執行的結果，當然，這個時候就要模擬Dao在返回幾種情況下服務的執行情況了，這個是正常的，就是去控制服務的輸入，^_^，這樣可以看到，其實在單元測試中是不會出現多少測試數據的情況的，除了Dao，而且也不用去關心其所依賴的對象的執行的正確與否，以及所依賴的對象是不是還依賴別的對象，^_^，可以保證測試的范圍就是本單元。
這樣做的潛在好處還在于會促進面向接口的編程，^_^
3、集成測試
集成測試就是需要創建出所依賴的對象的環境的一種測試方法，其實在有了單元測試的情況下，集成測試就可以完全的從系統的入口進行測試，例如B/S系統來講，它的入口都是頁面，也就是我們可以通過頁面來進行測試，這個時候可以看到，測試數據的問題又產生了...
當然，對于有些集成測試是需要編寫代碼的，這個時候就需要創建出入口對象所依賴的對象(以及它所依賴的對象)的環境，最后才能調用入口對象的方法進行測試，這樣就完成集成測試了。