很不幸地，而且通常大都是不幸的，你正在維護一個legacy 代碼，這個legacy code沒有完美的"代碼-接口"形式，雙重測試注入允許存在完美的"代碼-接口"。通常，這里在具體對象上有許多詳細的依賴項，很難用test doubles代替數據訪問對象，以此來模擬現場數據庫。在這些情況中，你的選擇要么在測試中，refactor legacy code來安裝，要么使用一個對象模擬工具（例如：TypeMock）。有了TypeMock，就可能模擬密封的和單一的類型－沒有這樣一個工具卻來實現一個感人的宴會。
Albeit很有力，除非非得需要，不然TypeMock就被放在旁邊；過早地使用TypeMock使得不編譯接口非常誘人。當操作遺留代碼-時間和預算允許時，更正確的方法就是refactor the code，取得更大的靈活性。Michael Feathers的《有效地與遺留代碼工作》是包含了很多關于如何在測試工作中重構遺留代碼的好辦法的書。
NHibernateDAO的單元測試
在這篇文章的前一版本，Nhibernate的ISession通過System.Runtime.Remoting.Messaging.CallContext單例保存和讀取。盡管非常適合WinForms 和單元測試，對ASP.NET 來說，卻是一個不好的方法，因為ISession 可能在載入時會丟失（這兩篇文章給予了進一步的解釋：為什么在ASP.NET應用程序里使用CallContext是一個壞的方法）。為了正確地與ASP.NET 應用程序連接，應該將ISession 儲存在HttpContext.Current.Items里，但是這樣做，當運行單元測試時，會強迫你模擬一個HTTP文本。它同樣阻止將結構簡單地傳遞到WinForms。一個更好的方法就是在它正確的時候，使用正確的repository。因此如果一個網頁文本可用，然后使用HttpContext；然而，使用CallContext. 將在后面討論這個結合方式的執行細節。（要感謝許多對這篇文章給予評論，從而引起了這個關注）。閱讀與怎樣管理ISession有關的
BasicSample.Tests/Data/CustomerDaoTests.cs這篇文章，因為單元測試HTTP-agnostic。一方面，你將在單元測試看到，除非你像在你的測試中改變數據，來服從于數據庫，反轉處理才是一個好的方法。
正如在示例中顯示的，可能創建一個通用的DAO，這個一般的DAO為任何持久穩固的對象工作。（后面將詳細討論）這就引起了應該測試什么以及怎樣測試它的爭論。每一個具體的DAO都要全面測試嗎？怎樣維護測試數據？個人經驗給出了這些建議：
• 保證每個泛型DAO中的每一個方法都有一個單元測試，例如，如果你有10個實現了泛型Dao的Dao，只有他們其中的一個需要被完全測試。單元測試中的實現了泛型DAO其他9個Dao只會提供很少的附加值。
• 確保每個從泛型Dao擴展的每個方法都有一個單元測試。例如，如果你有一個從泛型DAO繼承的CustomerDao 類并且增加了一個方法。如GetActiveCustomers(),那么這個單元測試應該測試這個擴展方法。
• 保證存在一個單元測試來完完全全測試每一個“專業” DAO。例如，DAO BasicSample.Data/HistoricalOrderSummaryDao.cs不是從一般DAO 繼承來的，將被看成是一個專業DAO。因此，存在一個單元測試來測試每一個方法。
• 在DAO單元測試被運行之前或者以后，都使用一個工具，例如NDbUnit，把測試數據庫放到一個已知的狀態。
• 使用如NDbUnit的工具測試數據庫在單元測試運行請后的狀態。 永遠記著，單元測試永遠不要依賴另外一個單元測試！他們應該是獨立并且可以獨立運行。例如一個刪除測試不應該依賴上一個插入測試的成功。注意TestFixtureSetUp和其他setup、teardown的方法，保證包含了這個能夠獨立運行的測試也能夠正常運行。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
