如何配置代码覆盖率以放宽对空条件运算符的评估规则？

我太懂这种两难的处境了——明明想把脆弱的链式成员访问改成更安全的?.空条件调用，结果代码覆盖率工具立刻跳出来要求你把每一个可能的null分支都写测试覆盖。尤其是在那种测试不足的大型遗留代码库中，光是构造出所有null场景（比如变量来自没法mock的私有方法）都难如登天，更别说写测试了，完全是在打击大家优化代码的积极性。

下面分享几个可行的思路，帮你解决这个问题：

1. 调整覆盖率工具的分支评估规则 #

主流的代码覆盖率工具（比如Visual Studio自带的覆盖率、Azure DevOps中使用的覆盖率工具）大多支持通过配置文件调整评估逻辑：

• 针对Visual Studio/Azure DevOps：可以创建或修改.runsettings配置文件，在其中自定义分支覆盖的判定规则。比如你可以添加规则，将空条件运算符?.的分支排除在强制覆盖要求之外。具体来说，可以在<CodeCoverage>节点下添加<Functions>或<Attributes>的排除规则，或者调整<BranchCoverage>的阈值设置，不过需要注意的是，不同版本的工具配置细节可能略有差异，你可以针对性地调整配置，忽略空条件运算符带来的额外分支。
• 使用单行注释跳过检查：如果只想忽略某一行的覆盖率分支要求，部分工具支持用特定注释标记，比如// coverage: ignore-line，让工具跳过当前行的分支覆盖验证。

2. 用辅助方法封装空条件链式调用 #

这是我在遗留代码里常用的技巧——把冗长的空条件链式调用封装成一个单独的辅助方法（比如扩展方法或工具类方法），然后在业务代码里调用这个方法：

// 封装到扩展方法里
public static string GetFinalValue(this YourVariableType variable)
{
    return variable?.Property?.InnerProperty?.InnerMostProperty?.FinalValue?.ToString();
}

// 业务代码里这样用
var result = variable.GetFinalValue();

这样一来，你只需要在辅助方法的单元测试里覆盖所有null分支，业务代码里的那一行调用只要执行过就算覆盖，不用在每个调用点都重复写测试。既保证了代码安全，又不用和覆盖率工具死磕。

3. 调整团队的覆盖率验收标准 #

有时候问题根本不在工具，而是团队的覆盖率要求太死板。你可以和团队成员商量：空条件运算符本身就是为了避免NullReferenceException的安全优化，这些null分支很多时候在现有代码逻辑里本来就不会出现（比如你提到的私有方法返回值不会为null，只是怕未来变更出问题），对于这类代码，可以放宽覆盖率要求，不需要强制覆盖所有分支。毕竟代码优化的优先级应该比覆盖率数字更高。

4. 退而求其次：用空合并运算符简化分支 #

如果上面的方法都不好实施，你也可以用空合并运算符??来减少需要覆盖的分支数，比如：

var finalValue = variable?.Property?.InnerProperty?.InnerMostProperty?.FinalValue ?? string.Empty;
var result = finalValue.ToString();

这样虽然还是有null分支，但至少把多个分支合并成了一个，测试起来会简单一些。

内容来源于stack exchange