我试图首先使用EntityFramework代码测试我的代码.为了使其可测试并允许隔离测试,我创建了一个我的DbContext实现的接口.我没有测试DbContext类 – 我将假设EF代码按预期工作.
现在,请考虑以下方法：
public IEnumerable<User> GetoddId() { return context_.Users.Where((u,i) => i % 2 == 1).AsEnumerable(); }
这个方法将通过我的模拟FakeDbSet传递(因为它将使用内存中的LINQ提供程序),而在使用EF / LINQ to sql驱动程序时它会因异常而失败.
你会不会留下它并希望人们知道不要写这样的问题？你会放弃隔离测试并测试实际的数据库吗？
具有DataMigrations的LocalDb(可能带有适当的种子)是否有助于对实际数据库进行测试？
请证明答案是正确的.
TLDR：如何测试EntityFramework代码,考虑内存LINQ和sql LINQ之间的差异？
很久以后编辑：我发现了一个非常好的框架,完全符合我的需要.我写了一篇关于unit testing with Effort的博客文章.另外请注意即将到来的EF6可能不需要这些,它承诺了一些单元测试功能.
解决方法
为此,我们使用sqlite的内存数据库.它们可以非常快速地创建,查询和拆除,并且几乎不会对整体测试速度产生任何影响.一旦您为自己设置了一个测试框架来创建数据库并注入数据,就可以快速编写测试.
当然,sqlite是一个比大多数人简单得多的数据库,因此复杂的查询可能无法转换为其sql版本,但是为了测试90％的情况,它运行良好.
这些测试是否构成集成测试？我不这么认为.它们仍然只测试一个代码单元,即生成LINQ查询的位.您正在测试两件事：1)查询返回正确的数据(但您可以使用内存中的集合检查这一点),以及2)查询可以由Entity Framework转换为有效的sql.测试后者的唯一真正方法是在真实的实体框架中使用存根数据库触发查询.
虽然你可以说真正的单元测试应该只测试你的代码的输出(即解析和检查已生成的表达式树),以及更难写,但它并没有真正证明什么.例如,如果您修改代码以生成内部联接而不是子查询,您是否希望测试中断？只有当它返回不同的结果时,我才会想到.
