單元測試策略，NHibernate的庫

我使用NHibernate和一個相當大的項目Repository模式，我試圖建立我的服務層單元測試策略和時遇到一些問題，讓在在我的腦海。我可能錯誤地接觸了單元測試，也可能是我錯誤地處理了Repository模式，但我不確定哪一個。單元測試策略，NHibernate的庫

我的方案的簡化子集是這樣的：

public class UserRepository : RepositoryBase, IRepository 
{ 

    public UserRepository() {} 
    public UserRepository(ISession sessionParam) { 
     session = sessionParam; // member of repository base 
    } 

    public string GetUsernameFromEmail(string emailAddress) { 
     return session.QueryOver<Members>().List().Where(u => u.EmailAddress.ToLowerInvariant() == emailAdrress.ToLowerInvariant()).FirstOrDefault().Username; 
    } 

}

我的單元測試的概念是，我會假NHibernate的ISession的，並傳遞一個返回的用戶列表，將適合的場景我」我試圖測試（例如，電子郵件地址是不區分大小寫的）（我也無法讓它與FakeItEasy一起工作，但這是另一個問題，我是否應該沿着這條路走下去）。請記住，我們不應該僞造我們不擁有的對象，我可以看到不想僞造ISession的邏輯，並且我一直在閱讀很多關於如何不測試存儲庫的內容 - 這也太遠遠低於單元測試。

但是，即使在有中，我想單元測試庫邏輯這個非常基本的情況。其他存儲庫方法可能會有更多的邏輯（例如數據驗證等）。我知道我可以使用SqlLite或類似的東西爲reporitory構建相對快速的集成測試，但在我看來，這個邏輯應該是單元測試的。

在庫依託有多數民衆贊成由一個Asp.Net MVC4現場消耗的（WCF）服務層。

在最好的世界中，我會在WCF層構建我的單元測試，並僞造IRepository進行測試，但我沒有看到如何在不讓所有用戶將此邏輯移動到服務層的情況下從存儲庫中返回到服務層，這看起來很荒謬。

所以我的問題是：什麼一塊整體架構這裏我有我的頭從根本上錯了嗎？

編輯

在迴應@ Wiktor的-zychla的答案，這是我關於我爲什麼要假的Isession邏輯。在考慮這個特定的測試時，我希望我的存儲庫使用ISession的實現，它總是返回一個具有混合大小寫的電子郵件地址和特定用戶名的用戶，傳遞所有小寫的電子郵件地址，並返回值是我指示我的假使用的用戶名。那樣，我正在測試我的邏輯是否有一個知道的值 - 無論NHibernate是否會在真實世界中運行，這不是我關心的問題 - 測試存儲庫方法中的邏輯是。再次，我知道這是一個微不足道，天真的例子，可以通過許多其他方式解決 - 它只是站在更復雜的功能上，我希望以後能夠測試。

來源

2013-07-31 cori

我不認爲你應該試圖僞造ISession。這沒有多大意義 - NHibernate存儲庫是一個抽象概念的具體實現，你想要測試的是這個具體實現是否可以，而不是進一步抽象並測試什麼？一個不同的假linq實現，然後假裝NH遵循它？在測試開始之前，讓你注入一個臨時的Isession到存儲庫，但仍的Isession指向一個真實的數據庫

單元測試應該涉及到一個真正的數據庫的話，很可能成立。

另一方面，當您測試使用存儲庫的服務時，將另一個存儲庫實現注入到服務層中是完全有效的。

來源

2013-07-31 17:48:51

感謝您的評論@Wiktor。我擔心的是，一旦我介紹一個實際的數據庫，我們不再談論單元測試 - 這些都是集成測試，我絕對必須這樣做，但這不是我在這裏問的。 – cori

沒必要。這正是邊緣情況之一，你需要考慮是否進一步抽象是有意義的。我對此的看法（我相信會分享給我的大多數人）將會是你無法可靠地僞造一個linq提供者，而這正是單元測試的必要條件。我的答案基本上是「不要單位測試這個你覺得似乎被吸引的東西」。 –

從你的評論我相信你正試圖把太多的責任放入庫層。非平凡的處理，validatiin等應該在上層完成，從而使其易於測試。想一想 - 你會在同一個存儲庫接口的兩個或多個實現中重複使用相同的驗證或處理邏輯嗎？ –

單元測試策略，NHibernate的庫

回答

相關問題