之前我問過這個問題How to correctly unit test my DAL?，有一件事情沒有給我答案，如果要真正測試我的DAL是有一個測試數據庫，那麼模擬與測試數據庫有什麼作用？嘲笑與測試數據庫？
爲了補充說明，另一個人建議「在單元測試結束時使用事務和回滾，因此db是乾淨的」，測試db。你們認爲這個測試+測試DB +事務回滾（所以db沒有真正寫入），測試DAL的方法是什麼？
爲了完整，我的DAL使用實體框架構建，數據庫中沒有存儲過程。由於EF非常新，我真的需要測試DAL以確保它們正常工作。
我想你可能會想要做一些集成測試來檢查由你的數據庫結構強制執行的邏輯，例如約束，觸發器，自動增量列等等。然而，你應該對單元測試模擬出任何框架你想要的DAL依賴的組件（在你的單元測試中）只測試你編碼的那些組件。您並不需要在SqlCommand或SqlConnection上測試方法（例如）。您應該假設您使用的框架組件工作併爲它們創建存根或嘲笑，將已知數據（好的，壞的，異常）返回給您的方法，以確保您的方法正常工作。不用嘲笑你負責在數據庫中生成數據並確保它是正確的。您還會在網絡，數據庫本身等上留下開放的依賴關係，這可能會讓您的測試變得脆弱。
此外，單元測試不會消除其他類型測試的需要。集成測試和驗收測試仍然有效，需要完成。他們可能不需要像單元測試那樣使用相同的頻率來完成，並且可能不需要像單元測試那樣提高代碼質量，但單元測試不是一個神奇的子彈。
通過使用測試數據庫，您可能會在數據庫本身或DAL和數據庫之間的通信路徑（網絡等）中引發問題。嘲笑消除了這些可能性。
當測試數據訪問代碼時，我沒有發現嘲笑非常有用。單元測試的目的是驗證與數據庫相關的代碼工作，並嘲笑數據庫會阻礙測試。
測試業務代碼時，Mocking確實變得有用。您可以模擬您的數據庫調用以返回測試數據，並在這些情況下驗證業務邏輯的行爲。
關於事務的使用 - 這當然是可能的，只要您的架構在測試開始時有足夠空間啓動事務，然後在該事務內部進行所有與數據庫相關的單元測試調用。雖然從未嘗試過。
我們使用了事務性單元測試，並且多次阻止了Hibernate映射問題。否則 - 單元測試是什麼？一些微不足道的東西，如List<Item> getAllItems()？ :)
把單元測試放入回滾聲音hacky的交易。 而不是我在測試運行之前（即在我的測試類的構造函數中）清除任何crud（即不是靜態/引用數據）的數據庫的代碼。當您的測試失敗時，它有助於讓數據仍在數據庫中，以檢查失敗的原因。
這不僅是您必須考慮的數據庫的狀態，它也是可用性。如果您的數據庫處於脫機狀態，那麼您的所有DAL測試都應該失敗？
您需要測試的是您的DAL發出正確的命令以創建/檢索/更新/刪除。您不需要爲此執行SQL，只需使用對象持久性框架並檢查是否給出了正確的說明。
這個問題很可能在原來的問題。
public class MusicStoreEntities : DbContext
{
public DbSet<Album> Albums { get; set; }
public DbSet<Genre> Genres { get; set; }
public DbSet<Artist> Artists { get; set; }
public DbSet<Cart> Carts { get; set; }
public DbSet<Order> Orders { get; set; }
public DbSet<OrderDetail> OrderDetails { get; set; }
}
對我來說這緊密結合的持久性的實現，我認爲這是一件壞事：有些MVC比較流行的例子返回一個DbSet如使用快捷方式。它會更好地返回List<t>這可能很容易被嘲笑。
不只是測試你的應用程序。您還在測試您的配置以及您的存儲過程和視圖。這些記錄在你的單元測試中。
有人建議用test db做事務和回滾，你怎麼看待這種測試DAL的方法？ – 2008-11-21 21:46:35
根據我的經驗，交易和回滾一直很慢。 – y0mbo 2008-11-21 21:51:39