为何使用空合并运算符(??)时单元测试覆盖率变化，三元运算符则达100%？

嘿，这个问题我之前也碰到过，来给你捋清楚～

首先，先还原一下你的代码场景（按常见写法模拟）：

1. 三元运算符实现的Employee类 #

class Employee {
    var id: Int?
    var name: String?
    
    func description() -> String {
        let idPart = id != nil ? "ID: \(id!)" : ""
        let namePart = name != nil ? "Name: \(name!)" : ""
        return "\(idPart) \(namePart)".trimmingCharacters(in: .whitespaces)
    }
}

2. 空合并运算符实现的版本 #

因为id是Int?，不能直接和空字符串合并，所以你大概率是用了map配合??（或者把id转成可选字符串）：

class Employee {
    var id: Int?
    var name: String?
    
    func description() -> String {
        let idPart = id.map { "ID: \($0)" } ?? ""
        let namePart = name.map { "Name: \($0)" } ?? ""
        return "\(idPart) \(namePart)".trimmingCharacters(in: .whitespaces)
    }
}

为什么覆盖率会不一样？ #

核心原因是两种写法的代码分支数量、以及编译器/覆盖率工具的解析逻辑不同：

三元运算符的分支逻辑

三元运算符condition ? expr1 : expr2是非常直白的二元分支：

• 当id != nil为true时，执行"ID: \(id!)"
• 当id != nil为false时，执行""

你的单元测试用例应该覆盖了所有4种场景：

• id和name都有值
• id有值、name无值
• id无值、name有值
• id和name都无值

这刚好覆盖了三元运算符的所有分支，所以覆盖率达到100%。

空合并+map的分支逻辑

而id.map { ... } ?? ""的写法，实际上拆解成了两层独立的逻辑：

1. id.map { ... }：这是可选值的map操作，包含两个分支：
   • 如果id有值，执行闭包内的代码（生成"ID: \($0)"）
   • 如果id无值，直接返回nil
2. ?? ""：空合并运算符，又包含两个分支：
   • 如果map的结果是nil（即id无值），返回空字符串
   • 如果map的结果有值，直接返回该值

虽然从功能上看和三元写法等价，但Xcode的覆盖率工具会把map的闭包、空合并的默认值分支都算成独立的可执行代码路径。

另外还有一个细节：??运算符的默认值参数是@autoclosure修饰的，这意味着只有当可选值为nil时，才会执行默认值的闭包。覆盖率工具会把这个@autoclosure的执行视为一个单独的代码块，需要被执行才算覆盖——而三元写法里的空字符串是直接字面量，没有额外的闭包执行逻辑，所以不会有这个额外的统计点。

怎么让??写法也达到100%覆盖率？ #

其实很简单，确保你的测试用例覆盖所有可能的代码路径：

• 测试id有值、name有值的场景（覆盖map闭包执行）
• 测试id有值、name无值的场景（覆盖name.map返回nil + ??取默认值）
• 测试id无值、name有值的场景（覆盖id.map返回nil + ??取默认值）
• 测试id无值、name无值的场景（覆盖两个map返回nil + 两个??取默认值）

只要这四个场景都跑过，??写法的覆盖率也会回到100%——大概率是你之前的测试用例虽然覆盖了逻辑，但没有完全触发??的所有底层代码路径（比如@autoclosure的执行）。

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