如何无冲突地针对数据库运行多个集成测试

更优解决方案 #

1. 基于事务回滚实现测试隔离 #

这是目前最推荐的方案，既支持xUnit并行运行，又无需频繁创建/删除数据库。核心思路是：每个测试启动时开启数据库事务，测试结束后直接回滚事务，所有测试共享同一个基础数据库，事务会隔离每个测试的修改操作，不会互相干扰。

示例代码：

public class OrderIntegrationTests : IDisposable
{
    private readonly OrderDbContext _dbContext;
    private readonly IDbContextTransaction _transaction;

    public OrderIntegrationTests()
    {
        var dbOptions = new DbContextOptionsBuilder<OrderDbContext>()
            .UseSqlServer("Server=(localdb)\\mssqllocaldb;Database=EFTTestBase;Trusted_Connection=True;")
            .Options;
            
        _dbContext = new OrderDbContext(dbOptions);
        // 确保基础数据库存在（仅首次运行时创建）
        _dbContext.Database.EnsureCreated();
        // 开启事务
        _transaction = _dbContext.Database.BeginTransaction();
    }

    public void Dispose()
    {
        // 回滚事务，丢弃所有测试产生的数据
        _transaction.Rollback();
        _dbContext.Dispose();
        _transaction.Dispose();
    }

    [Fact]
    public void CreateOrder_ShouldAddToDatabase()
    {
        // 测试逻辑：向_dbContext添加订单并保存
        var order = new Order { Id = 1, Amount = 99.9m };
        _dbContext.Orders.Add(order);
        _dbContext.SaveChanges();

        // 断言
        Assert.Single(_dbContext.Orders);
    }
}

这种方式的优势：

• 完全支持xUnit并行，事务隔离避免锁冲突
• 仅需初始化一次基础数据库，后续测试无需重复创建，大幅提升速度
• 无残留数据库文件问题

2. 内存数据库（限无特定SQL特性的测试） #

如果你的测试不需要依赖真实数据库的特性（比如SQL Server专属函数、存储过程、事务ACID特性验证），可以使用EF Core的内存数据库。每个测试实例生成一个唯一命名的内存数据库，天然支持并行，且速度极快。

示例代码：

[Fact]
public void CreateProduct_ShouldPersistInMemory()
{
    var dbOptions = new DbContextOptionsBuilder<ProductDbContext>()
        .UseInMemoryDatabase(databaseName: $"TestDb_{Guid.NewGuid()}")
        .Options;

    using var dbContext = new ProductDbContext(dbOptions);
    dbContext.Products.Add(new Product { Name = "Test Product" });
    dbContext.SaveChanges();

    Assert.Equal(1, dbContext.Products.Count());
}

注意：内存数据库不支持事务、SQL查询语法验证等特性，仅适合简单的业务逻辑测试。

3. 数据库快照快速重置 #

如果必须使用真实数据库且事务回滚无法满足需求（比如测试涉及跨事务操作），可以提前创建一个干净的测试数据库快照，每个测试启动时恢复快照，替代EnsureDeleted()/EnsureCreated()。恢复快照的速度远快于创建新数据库，且能保证每次测试都有干净的初始状态。

以SQL Server为例，可在测试初始化时执行快照恢复脚本：

RESTORE DATABASE EFTTestBase FROM DATABASE_SNAPSHOT = 'EFTTestBase_Snapshot'

测试结束调用EnsureDeleted()的潜在问题 #

• 残留数据库风险：若测试中途抛出异常（比如断言失败、代码报错），清理逻辑（如Dispose）可能无法执行，导致数据库残留，长期运行会积累大量无用数据库。
• 性能开销大：创建和删除数据库是重量级操作，尤其是数据库包含大量表结构时，30个测试的总耗时会显著增加。
• 权限与环境问题：部分测试环境（比如CI/CD流水线）可能限制数据库删除权限，导致测试失败；同时，并行删除数据库时可能出现锁冲突，引发删除失败。
• 资源浪费：频繁创建删除数据库会占用更多磁盘空间和数据库服务资源，尤其是在本地开发环境中，可能影响其他进程运行。

内容的提问来源于stack exchange，提问作者David Thielen