我最近一直在玩 ADO.NET Entity Framework，我发现它适合我正在开发的项目的需求。我也觉得它的非侵入性很酷。
从现有数据库生成数据模型后，您将面临集成生成模型和业务逻辑的任务。更具体地说，我习惯于集成测试我的类，这些类通过 DAL 接口的模拟/存根与数据存储交互。问题是您无法使用 ADO.NET Entity Framework 执行此操作，因为它生成的实体是没有接口的简单类。
问题是：如何将TDD 方法应用于开发使用 ADO.NET Entity Framework 的应用程序？这甚至可能还是我应该迁移到另一个 DAL 生成工具集？
尽管已经回答了原始问题，但我觉得我可能会添加一些内容：
我目前在我正在构建的 Intranet 站点上使用 Entity Framework 4.0。我可以使用已添加的 POCO 支持在没有数据库连接的情况下测试我的业务逻辑和控制器中的所有内容。
虽然 POCO 可以从 VS 2010 中包含的新 t4 模板生成，但我在 VS 2010 中找不到的是用于生成对象上下文的 t4 模板（对象上下文基本上作为内置单元工作EF 的工作量，对于将 EF 对象映射到 POCO 至关重要）。幸运的是， Joachim Lykke Andersen在他的博文Entity Framework 4.0 Beta 1 – POCO、ObjectSet、Repository 和 UnitOfWork中编写了一个 t4 模板来生成它，它非常有帮助。如果您使用无需数据库连接即可测试的 EF4 解决方案，我强烈建议您实施与他的解决方案类似的解决方案，其中包括通用存储库、工作单元包装器和工作单元工厂。这非常有帮助。
祝你好运。
我同意实体框架的版本 1 是对设计的犯罪，它肯定得到了我的不信任投票。我感谢 EF 产品团队承认失败并通过向社区开放他们的设计过程来做出回应。下一个版本不会是完美的，它甚至可能还没有准备好在生产级应用程序中使用，但我认为他们终于开始理解对于那些知道糟糕的设计是糟糕的业务的用户来说什么是重要的。话虽这么说……我还是很怀疑。持续的设计时反馈对这些人来说是新事物，我已经阅读了 ADO.NET 博客上的很多声明，这些声明引发了明亮的危险信号。我们将看到 .NET 4.0 的发布情况如何。
他们似乎正在尝试：
“持久性基础设施与实体类的紧密耦合在很大程度上消除了通过自动化测试在业务逻辑上有效使用非常紧凑的反馈周期的能力。在当前状态下，EF 实体类无法独立于数据库进行有效的单元测试。
行为对象的自动化单元测试的效率很大程度上取决于测试数据设置机制的简单程度以及测试执行的速度。使用实际数据库将使测试数据设置更加费力，引入数据以满足与测试无关的关系约束，并使测试执行速度慢一个数量级。
实体框架对基本软件设计原则（如关注点分离）的忽视损害了团队进行渐进式设计和增量交付的能力。”
从这里公然被盗： http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/
如果您专门研究 DAL 生成工具，您将很难将其与 TDD 集成。我知道的大多数 dal 生成工具也会生成您的业务对象并将它们与 DAL 紧密耦合，从而使测试变得困难。
您可以查看诸如 nHibernate 之类的 OR-mapping 工具，也许还有可以启用“持久性无知”的 Linq to sql，您可以自己定义业务对象，它们与 DAL 或任何其他基础设施代码没有链接。这使得与数据库分开测试您的业务逻辑变得更加容易。我发现它还可以更好地支持其他场景，例如偶尔连接的客户端。
此答案已更改为“是的，您可以”。
您可以使用自定义的 T4 模板（例如https://entityinterfacegenerator.codeplex.com/ ）生成 POCO 和接口，然后创建模拟对象以测试 EF 进出，而无需访问数据库。