我们如何测试 Entity Framework Core 中的连接弹性

Question

我已在 Entity Framework Core 中打开连接弹性：

services.AddDbContext<MyDbContext>( options =>
    options.UseSqlServer(Configurations["ConnectionString"]),
    sqlServerOptionsAction: sqlOptions =>
    {
        sqlOptions.EnableRetryOnFailure(
        maxRetryCount: 10,
        maxRetryDelay: TimeSpan.FromSeconds(5),
        errorNumbersToAdd: null);
    });

现在我想创建一些单元测试来证明这确实有效。可以做这样的事情吗？

似乎InMemoryDbContext没有该EnableRetryOnFailure方法，我能找到的最相似的测试是在 EF6 中： https ://thedatafarm.com/data-access/testing-out-the-connection-resiliency-feature-into-ef6/

（而且遵循起来有点复杂）

作为一些附加信息，我正在使用 SQL Server 2017 和 Entity Framework Core 2.2.0，当手动测试时，如果我使数据库脱机，它会立即失败。

我是否测试错误或者我缺少一些正确设置的东西？

Answer 1

Jeroen Mostert 在评论中回答了这个问题：

如果“使数据库脱机”的字面意思是将数据库状态设置为脱机，那么失败是预料之中的——这不是弹性防范的条件之一，因为它不是一种很可能及时自行解决的瞬态条件。如果服务器已启动但数据库已明确设置为脱机，您将立即将其作为错误返回 - 如果需要，添加重试取决于您的应用程序。要测试连接弹性，您必须关闭服务器本身 - 即关闭 SQL Server（或防火墙端口 1433，效果相同）。

顺便说一句，如果需要的话，errorNumbersToAdd 属性应该允许您将“数据库脱机”标记为暂时性错误 - 错误号为 942。仅当它在生产中也有意义时才使用它 - 否则，为了测试，它添加 50000 更有意义，这是自定义 RAISERROR 的错误号（例如 RAISERROR('这是一个暂时性错误！', 11, 0)），它很容易在查询中注入。当然，也不要在生产中使用它，因为大多数自定义错误不应该盲目地重试——使用像 Polly 这样的东西更有意义。

这似乎是最好的解释。