17、RSpec 测试框架使用指南：风险权衡与工具集成

RSpec 测试框架使用指南：风险权衡与工具集成

1. 状态与交互的权衡

在某些情况下，使用消息期望（message expectation）而非方法存根（method stub）可能不会带来太多额外价值。例如，第二个示例中使用消息期望的代码可能比第一个示例中使用方法存根的代码更冗长，并且与 header() 方法的底层实现绑定得更紧密。

然而，就像本章前面提到的日志记录器示例，消息期望是一个很好的应用场景，因为我们关注的是与协作者的交互，而非结果。通过对比图 14.5 左右两侧的图表，可以清晰地看到：当我们关注状态时，我们设计对象；当我们关注交互时，我们设计行为。这两种方法各有适用场景，但选择关注交互时，模拟对象（mock objects）能让我们更轻松地实现目标。

2. 测试替身的风险与权衡

在使用测试替身（test doubles）时，有一些常见的陷阱需要注意，以下是详细介绍：
- 过度指定（Over - specification） ：模拟对象的目的是为示例轻松设置上下文。如果一个示例中需要大量模拟对象，设置过程会变得冗长且容易混淆。因此，只指定当前示例绝对必要的内容。如果发现需要指定的内容过多，就应该重新评估设计，因为代码可能比预想的更具耦合性。
- 嵌套替身（Nested Doubles） ：替身不仅要易于设置，还应该尽量简单。虽然并非所有在替身上指定的方法都需要返回值，但很多情况下是需要的。通常，返回值最好是简单值，如语言原生类型或值对象。不过，当通过查询引入替身时（如之前章节所述），可以将查询方法存根为返回替身。当发