我熟悉用于测试 ASP .NET MVC 应用程序中的控制器和业务逻辑的技术。
我们的应用程序中的数据访问集中在松散耦合的特殊服务中，使用接口并通过实体框架与实际数据库一起使用。
然而，随着 DAL 变得越来越复杂，隐藏数据库实现细节并为应用程序代码提供抽象，我们开始担心是否能够通过任何方式对其进行测试。因为它已经与 EF 上下文紧密绑定，所以我们不打算引入另一个存储库样式层，但这也意味着我们不能仅使用虚假数据对其进行单元测试。
我在想是否可以以某种方式模拟或存根实体框架对象上下文，同时能够执行添加/删除实体和进行查询等简单操作.
我也在寻找关于这是否是一个好主意（也许真的很糟糕）的意见，如果不是，一些“智能”数据层测试建议。
如果您使用的话，模拟/存根 EF 是部分可能的IObjectSet以及派生的自定义接口ObjectContext实例和所有 EF 相关代码将仅通过这些接口访问 EF 功能（将注入上下文）。所有其他 EF 相关功能都必须隐藏在对象上下文接口上公开的方法中。
我在几个答案中讨论过（例如here https://stackoverflow.com/questions/5609508/asp-net-mvc3-and-entity-framework-code-first-architecture/5610685#5610685 and here https://stackoverflow.com/questions/5488313/organizationally-where-should-i-put-common-queries-when-using-entity-framework-c/5488947#5488947）这确实没有帮助，因为您没有测试真正的代码。非常大的问题是，一旦您模拟/存根 EF 代码，您就会将 linq-to-entities 替换为 linq-to-objects。另一个问题是您正在失去持久实体的引用完整性。因此，我认为 DAL、持久性和查询应该包含在使用真实 EF 和真实 DB 的集成测试中。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
