时间戳

首页 > 解决方案 > 我们如何在 Entity Framework Core 中测试连接弹性

sql-server - 我们如何在 Entity Framework Core 中测试连接弹性

问题描述

我在 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，当我手动测试时，如果我使数据库脱机，它会立即失败。

我是不是测试错了，或者我错过了正确设置的东西？

标签： sql-serverentity-framework-core

解决方案

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

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

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

这似乎是最好的解释。

推荐阅读