Typemock是唯一可以模擬Linq To SQL Table類的框架嗎？

Question

我想爲我的Linq To SQL代碼設置單元測試。我的代碼使用System.Data.Linq.Table類（由設計者生成）。

因爲這個類是密封的，構造函數是內部的，它完全是impervious to unit testing frameworks like Rhino Mocks。 （除非你想改變你的代碼來使用存儲庫模式，我寧願不使用它。）

Typemock可以（一些如何）模擬這個類。 （以here爲例。）

但是，Typemock也是800美元的許可證。我看不到我的僱主很快就會出現這種情況。

所以這裏是問題。有沒有其他嘲笑框架不依賴於接口來創建模擬？

---

編輯：代碼示例，我需要測試：

public class UserDAL : IUserDAL 
{ 
    private IDataClassesDataContext _ctx; 
    public UserDAL() 
    { 
     string env = ConfigurationManager.AppSettings["Environment"]; 
     string connectionString = ConfigurationManager 
            .ConnectionStrings[env].ConnectionString; 
     _ctx = new DataClassesDataContext(connectionString); 
    } 
    public UserDAL(IDataClassesDataContext context) 
    { 
     _ctx = context; 
    } 
    public List<User> GetUsersByOrganization(int organizationId) 
    { 
     IOrderedQueryable<User> vUsers = 
      (from myUsers in _ctx.Users 
      where myUsers.Organization == organizationId 
      orderby myUsers.LastName 
      select myUsers); 
     return vUsers.ToList(); 
    } 
    public bool IsUserInOrganization(User user, int orgainzationID) 
    { 
     // Do some Dal Related logic here. 

     return GetUsersByOrganization(orgainzationID).Contains(user);    
    } 
} 

我已經短路這件事，使之更易於閱讀。這個想法是，我有一些代碼（如IsUserInOrganization調用另一個，做一個LINQ查詢方法（如GetUsersByOrganization）。

我想單元測試IsUserInOrganization方法，不要做，我就需要模擬_ctx.Users 。這是一個表類（被密封並且具有內部的構造函數）

Answer 1

退房Microsoft Stubs擁有的簡單的前提：

更換任何.NET方法與自己的 委託！

並更詳細地描述了它的功能（重點是我的）。

存根是完全基於代表用於 測試存根和彎路在.NET是 輕質框架，生成的類型 安全，refactorable和源代碼 。存根設計提供了 對Pex白色的最小開銷 框分析，支持代碼 合同運行時寫入程序和 鼓勵編程模型 而不是記錄/重放測試。 存根可用於任何.NET方法，包括密封類型的非虛擬/靜態方法 。關於代碼

Answer 2

有兩種標準單元測試在這種情況下接近：

1）不要測試平臺 - 如果相關性是在框架類，你不寫測試在那裏交互驗證。這通常意味着您在測試時替換依賴項，但在您的情況下，它可能意味着您要注入表本身。

2）包裹平臺 - 如果你需要測試的東西，與平臺互動，然後編寫相關組件

了一層包裝還有集成與驗收測試的考慮。對於這兩種情況，您通常會簡單地接受依賴項，因爲它存在於您的應用程序中。

你究竟在考慮什麼，你需要直接模擬/替換這個類呢？

編輯：

看來，如果你正在尋找避免重寫代碼更加可測試。這就是TypeMock擅長的地方，也是一些測試擁護者認爲TypeMock會導致問題的原因。但是，如果您絕對拒絕重構代碼的可測試性，那麼這是您工作的正確工具。

編輯＃2：

也許我過於迷戀這個，但讓我們考慮一個更容易測試模式：

Organization() 
{ 
    HasUser(name) 
} 

OrganizationDAL 
{ 
    Organization LoadOrganization(id) 
} 

OrganizationServiceFacade 
{ 
    IsUserInOrganization(name, orgid) 
    { 
     return OrgDAL.LoadOrganization(id).HasUser(name) 
    } 
} 

組織自然包含測試用戶不再需要爲平臺獨立的，你應該能夠注入數據源。OrganizationDAL僅負責加載組織，而不是返回有關組織的信息（儘管有必要的話可以將查詢放入此層）。 OrganizationServiceFacade僅負責提供組合服務，既要滿足可模擬性，又要避免額外的單元測試（它是一個集成或可能甚至是一個接受目標），因爲它是一個包裝類。根據您構建組織的方式，您可以注入數據而不依賴於數據如何工作的特定概念。

Answer 3

您可能需要考慮使用Repository模式，基本上它是Mike提出的「包裝平臺」建議。有了它，你會嘲笑IRepository而不是DataContext。

http://blogs.microsoft.co.il/blogs/kim/archive/2008/11/14/testable-data-access-with-the-repository-pattern.aspx