模拟ObjectContext,处理ObjectQuery.Include(string)方法?

时间:2010-06-04 17:59:29

标签: .net linq-to-entities wcf-ria-services

我一直在研究如何将我的DomainServices与其数据源分离,以便我可以在单元测试中测试它们。我开始认为完全脱钩是不可能的。

有大量信息,例如此question和此blog post。特别是博客文章让你真的很嘲笑ObjectContext。

但我的DomainServices有这样的方法:

public IQueryable<Client> GetClients()
{
    return ObjectContext.Clients
        .Include("Foo")
        .Include("Bar")
        .Where(c => c.IsBaz);
}

似乎无法完全模拟Include方法,因为它返回ObjectQuery<T>,并且在任何地方都没有捕获Include方法(没有IObjectQuery接口)。 ObjectQuery实现IQueryable<T>,因此我认为使用我自己的返回IQueryable的Include方法可以正常工作,但前提是我计划每次查询最多调用一次Include。

我正在使用EF4,.NET 4,Silverlight 4和RIA Services RTW。

作为一个咆哮,我对如何测试不友好的LINQ to Entities和扩展RIA服务是如何感到失望:(

1 个答案:

答案 0 :(得分:1)

我认为你不应该在那个级别进行单元测试。我全都参加单元测试,但有一点你需要停下来。

让我们说代码是ClientsLinqRepository的一部分,ClientsLinqRepository又实现了IClientsLinqRepository。在实现依赖于它的代码时,您可以模拟IClientsLinqRepository。

虽然上述内容完全有效,但ClientsLinqRepository是一个集成实现。就像你有IMessageSender并且实现了MailSender一样。在这里你有代码,它的主要职责是与一个单独的系统集成,对你来说就是数据库。

根据上述情况,我建议您在该课程上进行一些重点集成测试。因此,在这种情况下,您确实想要访问外部系统(数据库),并确保集成代码与外部系统正常工作。它允许您快速识别代码与数据库中的任何内容是否被破坏而不处理系统其余部分的复杂性(这在尝试在其他级别进行集成测试时会很痛苦。)

将重点集成测试与单元测试分开,这样您就可以根据需要运行速度惊人的单元测试,并在对任何集成部分进行更改时运行集成测试。 / p>