如何测试EF Core事务提交失败以验证事务弹性？

针对EF Core事务提交失败（低概率但可能导致重复行）的场景，可通过以下可控方式开展测试：

• 自定义EF Core拦截器模拟提交失败
  实现DbCommandInterceptor，在事务提交的关键节点抛出异常，精准模拟提交失败。比如在TransactionCommitStarting方法中，判断当前操作是事务提交时，抛出对应数据库的异常（如SqlException，指定连接超时或提交失败的错误码）。这种方式无需外部工具，完全在代码层面控制失败时机，适合单元测试集成。

  示例代码片段：

  public class FailCommitInterceptor : DbCommandInterceptor
  {
      public override InterceptionResult<int> TransactionCommitStarting(
          DbTransaction transaction,
          TransactionEventData eventData,
          InterceptionResult<int> result)
      {
          // 可添加开关控制是否触发失败，方便正常/异常场景切换
          if (ShouldFailCommit())
          {
              throw new SqlException("模拟事务提交失败", (int)SqlErrorCodes.TransactionCommitFailed);
          }
          return base.TransactionCommitStarting(transaction, eventData, result);
      }
  }
  

  注册拦截器后，执行事务提交逻辑即可触发模拟失败，验证系统是否能正确处理，以及是否出现重复行。

• 模拟网络/数据库连接中断
  在事务执行到提交步骤时，手动切断应用与数据库的连接：

  • 本地测试可借助网络工具（如Linux的tc命令限制网络延迟/丢包，Windows的防火墙临时阻断数据库端口）；
  • 容器化环境可通过Docker的网络命令断开容器与数据库的连接；
  • 云数据库可利用厂商提供的故障注入工具模拟连接中断。

• 数据库端强制触发提交失败
  针对特定数据库执行干预操作，比如在事务提交前，手动锁定目标表或终止数据库连接。以SQL Server为例，可在另一个会话中执行KILL <spid>终止当前事务的数据库进程，或者设置表级锁导致提交超时。

• 重复执行+随机失败注入
  编写循环执行的测试用例，在每次事务提交前随机触发失败（结合拦截器或网络模拟），大量重复执行后统计是否出现重复行。这种方式能模拟低概率场景的累积效应，验证系统的长期弹性。

• 验证重试策略的正确性
  对比开启/关闭EF Core连接弹性重试策略的测试结果：开启重试时，检查系统是否会在提交失败后正确判断重试安全（避免重复插入）；关闭重试时，确认是否能正确捕获异常并回滚（或提示用户）。

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