本文详解如何使用 spock 框架精准验证 mock 对象方法的**调用顺序与具体参数**，通过 `then:` 块分段断言实现时序敏感的交互测试，避免仅校验调用次数导致的逻辑漏洞。
在 Spock 单元测试中，验证方法是否被调用、调用几次相对简单（如 2 * foo.bar(_)），但若业务逻辑依赖严格的调用时序与参数组合（例如先处理 ‘a’ 再处理 ‘b’），仅检查总次数将无法捕获顺序错误——比如 foo.bar(‘b’) 先于 ‘a’ 被调用，或两次均传入 ‘a’，这类缺陷会被漏过。
Spock 提供了简洁而强大的机制：将 then: 块拆分为多个独立的、按执行顺序排列的断言块。每个 then: 块对应一次预期的交互，Spock 会严格按代码顺序匹配实际调用流，确保前一个断言满足后，才进入下一个断言的验证。
以下为正确写法示例：
def "myMethod calls foo.bar with ‘a’ then ‘b’ in order"() { given: def foo = Mock(Foo) def myClass = new MyClass(foo: foo) when: myClass.myMethod(‘a’, ‘b’) then: 1 * foo.bar(‘a’) // 第一次调用必须是 bar(‘a’) then: 1 * foo.bar(‘b’) // 第二次调用必须是 bar(‘b’)}
✅ 关键原理说明：
Spock 将每个 then: 视为一个独立的“交互阶段”，按源码顺序依次激活； 在第一个 then: 中，Spock 仅等待并匹配第一次对 foo.bar(‘a’) 的调用； 进入第二个 then: 后，Spock 自动忽略此前已匹配的调用，只关注后续发生的下一次调用，并严格校验其为 foo.bar(‘b’)； 若实际调用顺序为 bar(‘b’) → bar(‘a’)，或两次均为 bar(‘a’)，测试将立即失败，并给出清晰的 mismatch 报告（如 “Expected call to … but was …”）。
⚠️ 注意事项：
不可将两个断言写在同一 then: 块内（如 1 * foo.bar(‘a’); 1 * foo.bar(‘b’)），这等价于“任意顺序调用一次 ‘a’ 和一次 ‘b’”，不保证时序； 确保 given: 中正确注入 mock 实例（如示例中通过构造函数或 setter 注入 foo），否则 foo 为 null 将导致 NPE； 若方法可能被调用多次且需验证完整序列（如 3 次以上），可继续追加 then: 块，Spock 仍保持线性时序约束； 对于更复杂的交互（如带副作用的 stubbing 或条件分支），建议结合 >> 返回值与 >> { … } 闭包增强可读性，但时序验证仍应优先使用多 then: 结构。
总结而言，多 then: 断言是 Spock 实现“有序交互验证”的标准、可靠且语义明确的方式。它将测试意图直接映射为代码结构，大幅提升测试的可维护性与故障定位效率——当测试失败时，你一眼就能看出是哪一步顺序或参数出错，而非陷入模糊的“调用次数不符”排查中。
评论(0)