c# - 如何对 Entity Framework 进行单元测试？

Question

我尝试先使用 EntityFramework 代码测试我的代码。为了使其可测试并允许进行隔离测试，我创建了一个由我的 DbContext 实现的接口(interface)。我没有测试 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:考虑到内存中 LINQ 和 SQL LINQ 之间的差异，如何测试 EntityFramework 代码？

很久以后的编辑:我已经找到了一个非常好的框架，它完全可以满足我的需要。我写了一篇关于 unit testing with Effort 的博文.另请注意，即将推出的 EF6 可能不需要所有这些，它 promise 提供一些单元测试功能。

Answer 1

为此，我们使用 SQLite 的内存数据库。它们的创建、查询和拆除速度非常快，几乎不会对整体测试速度产生任何影响。一旦您为自己设置了一个测试框架来创建数据库并注入(inject)数据，就可以快速编写测试。

当然，SQLite 是一个比大多数数据库都简单得多的数据库，因此复杂的查询可能无法转换为其 SQL 版本，但对于测试 90% 的情况，它运行良好。

这些测试是否构成集成测试？我不这么认为。他们仍然只测试您的 代码的一个单元，即生成 LINQ 查询的位。您正在测试两件事:1) 查询返回正确的数据(但您可以使用您所说的内存中集合来检查)，以及2) Entity Framework 可以将查询转换为有效的 SQL。测试后者的唯一真实方法是在真实的 Entity Framework 中触发查询，但使用 stub 数据库。

虽然您可能会争辩说真正的单元测试应该只测试代码的输出(即解析和检查已生成的表达式树)，而且更难编写，但它并不能真正证明任何事情。例如，如果您修改代码以生成内部联接而不是子查询，您是否希望测试中断？只有当它返回不同的结果时，我才会想到。