RSpec多简单断言示例最佳格式化实践：测试is_multiple_of_3_or_5?方法

关于重构的价值问题 #

首先需要明确：你最初的写法是无法正常运行的。RSpec 要求所有 expect 断言必须包裹在 it 示例块中，直接写在 context 层级会直接抛出语法错误，所以哪怕你不追求规范，也至少要做基础的示例拆分才能让测试生效。

抛开语法错误不谈，即使是简单的整数测试场景，拆分单断言的重构也是收益远大于成本的：

• 单断言的测试失败时会直接明确提示哪个输入值不符合预期，不需要逐行翻错误日志定位故障点；如果多个断言塞在同一个示例中，第一个断言失败后后续断言会直接跳过，你没法一次性拿到所有失败的测试值，排查问题的效率会低很多。
• 看似代码量变长了，但后续新增测试值、调整断言逻辑的成本会低得多，尤其当这个方法后续逻辑迭代需要补充边界用例（比如0、负数、超大数）的时候，结构清晰的测试改起来效率高得多。

关于两种重构版本的规范度问题 #

两种写法都符合「单示例单断言」的基础规范，适用场景略有区别：

• 第一种逐行写 it 块的写法逻辑更直白，没有RSpec DSL的学习门槛，对RSpec不熟悉的团队成员也能一眼看懂，适合测试逻辑简单、几乎不会有后续迭代的一次性测试用例。
• 第二种使用 subject + let + is_expected 的写法更符合RSpec的惯用范式，复用性更强：如果后续要补充负向测试（比如输入不是3或5倍数的场景），只需要新增context复用subject逻辑即可，不需要重复写 expect(is_multiple_of_3_or_5?(xxx)) 这段冗余代码，更符合DRY原则，是社区更推荐的写法。

如果追求更简洁的多值测试，还可以使用RSpec参数化扩展来进一步压缩重复代码，同时保留单断言的优势。

内容的提问来源于stack exchange，提问作者Georges Atalla