Spock验证Mock调用顺序与参数方法

本文深入解析了 Spock 框架中通过多 `then:` 块实现方法调用顺序与参数的精准验证——不同于简单统计调用次数，Spock 利用按序激活的独立断言阶段，严格匹配每次交互的发生时机和具体入参（如必须先调 `bar('a')` 再调 `bar('b')`），从而捕获因时序错乱或参数误传引发的隐蔽逻辑缺陷；这种结构清晰、失败信息明确的验证方式，不仅让测试意图一目了然，更显著提升了交互式场景下测试的可靠性与可调试性。

本文详解如何使用 Spock 框架精准验证 mock 对象方法的调用顺序与具体参数，通过 then: 块分段断言实现时序敏感的交互测试，避免仅校验调用次数导致的逻辑漏洞。

本文详解如何使用 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 实现“有序交互验证”的标准、可靠且语义明确的方式。它将测试意图直接映射为代码结构，大幅提升测试的可维护性与故障定位效率——当测试失败时，你一眼就能看出是哪一步顺序或参数出错，而非陷入模糊的“调用次数不符”排查中。

今天关于《Spock验证Mock调用顺序与参数方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！