单元测试与集成测试:实体框架核心在内存中

Question

我目前正在使用EF Core 2.0开发ASP.NET Core 2.0 Web API.我计划实现Repository + UnitOfWork模式,我已经创建了抽象,接口等.由于我遵循TDD方法,我想在继续执行之前在这些接口上编写测试.

我面临的问题主要与语义有关.我在我的解决方案中创建了两个项目,一个用于单元测试,一个用于集成测试.对我来说很明显,同样测试数据库的测试不是单元测试,因此应该放在IntegrationTests项目中.但事实是,我正在计划使用EntityFrameworkCore.InMemory提供程序,并为每个测试启动虚假的内存数据库.

所以每个测试都应该有这样的结构:

[TestClass]
public class GamesRepositoryTest
{
    AppDbContext _context;
    IGamesRepository _repository;

    public GamesRepositoryTest()
    {

    }

    [TestInitialize]
    public void Initialize()
    {
        DbContextOptionsBuilder<AppDbContext> builder = new DbContextOptionsBuilder<AppDbContext>().UseInMemoryDatabase(databaseName: Guid.NewGuid().ToString());
        _context = new AppDbContext(builder.Options);
        _repository = new GamesRepository(_context);
    }

    [TestCleanup]
    public void Cleanup()
    {
        _context.Database.EnsureDeleted();
    }
}

所以我的问题是,EntityFrameworkCore.InMemory是否提供了足够的抽象级别,以便上面的类可以被认为是单元测试,还是应该将它放在IntegrationTests项目中？

Answer 1

新的内存提供商将每个人的内容搞糊涂了.首先,让我们的目的得到澄清:它是一个测试数据提供者.而已.您可以轻松地模拟DbContext并返回静态列表或其他内容.内存提供程序只是为您提供了一种更简单的方法来设置该测试支架.它不适合集成测试,因为您实际上不会在生产中使用它.正确的集成测试将真正实现您的生产设置的传真.

也就是说,实体框架核心的新内存提供商的主要问题是,现在人们似乎在滥用它来测试他们不应该测试的东西.EF核心已经是经过严格测试的,所以你应该只测试您的应用程序代码.再一次,只需将它想象成一个模拟而不必实际设置模拟.只要你这样做,你应该没事.

基于这一切,要回答您的问题,您的测试应该是单元测试,如果除了您实际创建集成测试之外没有其他原因,您不应该使用内存提供程序.只要确保你实际上正在进行单元测试.