ASP.NET Core 2.0单元测试并行运行时EF Core实体跟踪冲突求助

看起来你已经做了正确的基础工作——用唯一数据库名和独立服务提供程序，但并行测试时的实体跟踪错误，核心问题还是DbContext实例被意外共享了，或者服务提供程序的复用导致了隐性状态共享。下面是具体的解决措施：

1. 确保每个测试拥有完全独立的DbContext实例 #

XUnit默认会并行运行同一程序集中的测试类，如果你在测试类的静态字段、IClassFixture/ICollectionFixture中存储DbContext，不同测试会同时访问同一个实例，必然导致跟踪冲突。

正确的做法： #

把DbContext的创建封装成一个独立方法，每个测试方法内部调用这个方法获取全新实例，并用using语句管理生命周期，确保测试结束后上下文被及时释放：

private MyDatabaseContext CreateIsolatedDbContext()
{
    // 每次都创建全新的服务提供程序
    var serviceProvider = new ServiceCollection()
        .AddEntityFrameworkInMemoryDatabase()
        .BuildServiceProvider();

    var options = new DbContextOptionsBuilder<MyDatabaseContext>()
        .UseInMemoryDatabase(databaseName: Guid.NewGuid().ToString())
        .UseInternalServiceProvider(serviceProvider)
        .EnableSensitiveDataLogging()
        .Options;

    return new MyDatabaseContext(options);
}

// 在测试方法中使用
[Fact]
public async Task WhenAddingEntity_ShouldPersistSuccessfully()
{
    using var context = CreateIsolatedDbContext();
    
    // 执行测试逻辑：添加实体、保存、查询验证
    var entity = new SomeModelObject { Id = 1, Name = "Test" };
    context.SomeEntities.Add(entity);
    await context.SaveChangesAsync();

    var retrieved = await context.SomeEntities.FindAsync(1);
    Assert.Equal("Test", retrieved.Name);
}

2. 绝对禁止复用静态资源 #

不要用静态字段存储ServiceProvider、DbContextOptions或DbContext实例——静态资源会被所有测试共享，即使你用了唯一数据库名，服务提供程序内部的EF核心服务可能存在隐性状态共享，导致跟踪冲突。

3. 避免在共享Fixture中创建DbContext #

如果你使用了XUnit的Fixture特性：

• IClassFixture会在测试类的所有测试方法间共享实例，不适合存储DbContext
• ICollectionFixture会跨测试类共享，更不能用于创建DbContext

如果需要复用测试数据初始化逻辑，可以把初始化逻辑封装成方法，每个测试调用时传入自己的DbContext实例。

4. 临时禁用并行测试（用于排查） #

如果以上调整后问题仍存在，可以临时禁用XUnit的并行测试来验证问题根源：
在项目根目录创建xunit.runner.json文件，内容如下：

{
  "parallelizeTestCollections": false
}

注意这是临时排查方案，解决根本问题后建议恢复并行，保证测试效率。

为什么会出现这个错误？ #

当多个并行测试共享同一个DbContext时，不同测试的实体操作会同时触发上下文的跟踪机制，同一个键值的实体可能被多个测试操作添加到跟踪队列，就会抛出你看到的InvalidOperationException。单独运行时每个测试独占上下文，所以不会有冲突。

内容的提问来源于stack exchange，提问作者Paolo Tedesco