使用dotCover且开启代码优化时，传入double.NaN的单元测试异常问题咨询

这确实是Release模式下配合dotCover做覆盖率分析时容易碰到的一个诡异坑，我来帮你梳理清楚问题并给出不影响业务逻辑的修复方案：

问题背景与异常现象 #

当运行单元测试时，测试用例传入double.NaN作为参数，方法里的逻辑是判断该参数是否超出0.0至30.0的范围，若超出则触发Assert.Fail()。

按照正常的C#逻辑，double.NaN和任何值比较的结果都是false，所以理论上绝对不应该进入Assert.Fail()分支。但当代码开启了代码优化（比如使用Release配置），同时配合dotCover进行覆盖率分析时，却会意外进入该分支——甚至输出显示三个比较结果（value < 0.0、value > 30.0等）全为false，但分支还是执行了。

不改变业务逻辑的修复方式 #

以下几种方案都能解决这个异常，且完全保留原本的业务判断逻辑：

• 将比较结果赋值给局部变量
  先把每个比较的结果存储到局部bool变量中，再用这些变量构建判断条件。这样能避免编译器优化和dotCover的插桩逻辑干扰判断逻辑：

  bool isBelowMin = value < 0.0;
  bool isAboveMax = value > 30.0;
  if (isBelowMin || isAboveMax)
  {
      Assert.Fail("参数超出允许范围");
  }
  

• 拆分复合if语句
  把原本的复合判断拆成两个独立的if分支，分别检查上下边界：

  if (value < 0.0)
  {
      Assert.Fail("参数超出允许范围");
  }
  if (value > 30.0)
  {
      Assert.Fail("参数超出允许范围");
  }
  

  拆分后每个判断逻辑独立，不会因为编译器的优化逻辑导致复合条件的异常判定。

• 使用非短路逻辑或|代替短路||
  把逻辑或的短路运算符||换成非短路的|，强制编译器执行所有比较操作，避免优化带来的逻辑偏差：

  if (value < 0.0 | value > 30.0)
  {
      Assert.Fail("参数超出允许范围");
  }
  

  注意这里用|而非||，这样两个比较都会被执行，不会因为第一个结果为false就跳过第二个，从而避免dotCover分析时的异常。

• 显式检查double.NaN
  直接在边界判断前明确检查参数是否为NaN，从根源上处理这个特殊值的情况：

  // 若原本业务逻辑中NaN不属于"超出范围"，则调整判断逻辑如下
  if (!double.IsNaN(value) && (value < 0.0 || value > 30.0))
  {
      Assert.Fail("参数超出允许范围");
  }
  

  这种方式最直接，明确区分了NaN和正常数值的判断逻辑，彻底避免了比较异常。

内容的提问来源于stack exchange，提问作者Jörg Penndorf