测试驱动开发和ADO.NET实体框架

Question

我最近一直在使用ADO.NET实体框架，我发现它适合我正在开发的一个项目的需要。我也发现它的非侵入性很酷。

从现有数据库生成数据模型后，您将面临集成生成的模型和业务逻辑的任务。更具体地说，我习惯于集成测试我的类，这些类通过DAL接口的模拟/存根与数据存储交互。问题是您不能使用ADO.NET实体框架做到这一点，因为它生成的实体是没有接口的简单类。

问题是:如何将测试驱动开发方法应用于使用ADO.NET实体框架的应用程序的开发？这是可能的吗?或者我是否应该迁移到另一个DAL生成工具集？

Answer 1

对实体框架的一大批评是，它天生就很难测试，例如在全球环境基金引用的ALT.Net Vote of No Confidence中。

Here is a blog post讨论了如何解决这个问题，并在使用实体框架时能够在不影响数据库的情况下测试代码。

如果可测试性是一个很大的问题，那么至少在Entity Framework2.0发布之前，您可能需要考虑另一个对象关系管理框架，比如NHibernate。

Answer 2

虽然，最初的问题已经得到了回答，但我觉得我可能会补充一些：

我目前正在构建的intranet站点上使用Entity Framework4.0。使用添加的POCO支持，我可以在没有数据库连接的情况下测试业务逻辑和控制器中的所有内容。

虽然，POCO可以从VS2010中包含的新t4模板生成，但我在VS2010中找不到的是用于生成对象上下文的t4模板(对象上下文基本上是EF的内置工作单元，对于将EF对象映射到POCO是必不可少的)。幸运的是，Joachim Lykke Andersen在他的博客文章Entity Framework 4.0 Beta 1 – POCO, ObjectSet, Repository and UnitOfWork中写了一个t4模板来生成它，它非常有帮助。如果您追求的是使用EF4的解决方案，并且可以在没有数据库连接的情况下进行测试，我强烈建议您实现类似于他的解决方案的东西，其中包括通用存储库、工作单元包装器和工作单元工厂。这是非常有帮助的。

祝你好运。

Answer 3

我同意实体框架的版本1是对设计的一种犯罪，它绝对得到了我的不信任票。不过，我相信EF产品团队承认失败，并通过向社区开放他们的设计过程来做出回应。下一个版本不会是完美的，它甚至可能还没有准备好在生产级应用程序中使用，但我认为他们终于开始理解对于那些知道糟糕的设计就是糟糕的业务的用户来说，什么是重要的。话虽如此..。我还是很怀疑。对于这些人来说，持续的设计时反馈是新的，我在ADO.NET博客上读到了相当多的声明，这些声明提出了鲜明的危险信号。我们将看看.NET 4.0的发布情况如何。

不过，他们似乎在尝试：

Test-Driven Development Walkthrough with the Entity Framework 4.0