unit-testing - EF4.1 DbSet 与 EF4 ObjectContext 和单元测试

Question

我目前有一个使用 EF4 启动的项目，并在事后返回并添加单元测试。我正在使用EF4 POCO T4 templates与我的模型(数据库)第一个上下文。我使用通用存储库来存储 DAC 逻辑，并使用工作单元模式来实现持久性。

但是，我在理解如何模拟 ObjectContext/ObjectSet 时遇到了一些问题。我查看了使用 FakeObjectSet<T>样本来自this article ，但它仍然遗漏了一些东西，例如自动递增身份和事务回滚。

因此，我正在尝试找到一个良好的 EF 设计，该设计仍然可以完全进行单元测试。

我的问题是，EF4.1 DbSet 是否解决了 EF4 单元测试的许多问题？有没有关于设计可完全测试的 EF4.1 解决方案的优秀综合文章？

另外，请记住，我需要一个模型优先的解决方案。

提前致谢。

Answer 1

完全模拟模拟层的行为不是单元测试的重点。单元测试的要点是相信模拟层可以正常工作。单元测试验证测试方法而不是模拟方法。您只需验证是否调用了模拟上的正确方法，如果您的业务逻辑需要某些值，也许您将设置一些回调来修改传递的数据。示例:

您有一个业务方法，将记录插入数据库并在插入后使用实体及其 ID。 IObjectSet 模拟将配置为:

• 设置仅调用一次 AddObject 的预期 - 您可以在验证中设置预期实例
• 您可以为 AddObject 定义回调，将 Id 设置为某个值并在稍后的测试中使用它

DbSet 不会有任何区别 - 它只是具有类似行为的 ObjectSet 的包装。在我看来，没有有效的方法可以让模拟表现得像真正的 EF。创建具有模拟 EF + 数据库行为的模拟所需的工作量将比整个应用程序的工作量大得多!这将不再是 mock ，它将是假的 EF 提供商。

如果您想测试您的 EF 代码(映射、查询、持久化)和数据库行为(如自动增量、事务等)，您必须编写集成测试。这里有一些讨论存储库、工作单元和测试挑战的相关问题:

• ASP.NET MVC3 and Entity Framework Code first architecture
• Organizationally, where should I put common queries when using Entity Framework Code First?