人们如何使用实体框架6进行单元测试，您是否应该感到困扰？
我只是从单元测试和一般的 TDD 开始。我之前已经涉猎过，但现在我决心把它添加到我的工作流程，并编写更好的软件。
我昨天问了一个类似于这样的问题，但它本身似乎就是一个问题。我已经坐下来开始实现一个服务类，我将使用它从控制器中抽象出业务逻辑，并使用 EF6映射到特定的模型和数据交互。
问题是我自己已经设置了路障，因为我不想把 EF 抽象到存储库中(它仍然可以在服务之外用于特定的查询等) ，并且想测试我的服务(将使用 EF Context)。
我想问题是，这么做有意义吗？如果是这样的话，那么在 IQueryable 引起的抽象漏洞以及 Ladislav Mrnka关于单元测试的许多重要文章中，由于 Linq 提供者在处理与特定数据库相对应的内存实现时存在差异，人们是如何在野外做到这一点的呢。
我想测试的代码看起来很简单。(这只是一个虚拟的代码来尝试和理解我在做什么，我想用 TDD 驱动创建)
背景
public interface IContext
{
IDbSet<Product> Products { get; set; }
IDbSet<Category> Categories { get; set; }
int SaveChanges();
}
public class DataContext : DbContext, IContext
{
public IDbSet<Product> Products { get; set; }
public IDbSet<Category> Categories { get; set; }
public DataContext(string connectionString)
: base(connectionString)
{
}
}
服务
public class ProductService : IProductService
{
private IContext _context;
public ProductService(IContext dbContext)
{
_context = dbContext;
}
public IEnumerable<Product> GetAll()
{
var query = from p in _context.Products
select p;
return query;
}
}
目前我的心态是做几件事:
- 使用类似这样的方法模仿 EF Context —— 单元测试时嘲笑 EF或者直接在接口上使用模仿框架，比如 moq ——承受单元测试可能通过但不一定能够工作的痛苦，并用集成测试来支持它们？
- 也许使用类似 努力的东西来嘲笑 EF-我从来没有使用过它，也不确定是否有其他人在野外使用它？
- 不必费心测试任何简单地调用 EF 的东西——所以直接调用 EF 的服务方法(getAll 等)本质上不是单元测试，而只是集成测试？
有没有人在没有回购协议的情况下成功地完成了这件事？
最佳答案