RSpec 和 Cucumber 有什么区别？开发者测试与业务验收的分工
RSpec 用 Ruby 描述代码行为，Cucumber 用自然语言描述业务场景。本文从测试写法、适用层、维护成本与协作模式对比两者，讲清 BDD 工具的真实分工与组合用法。
RSpec 和 Cucumber 解决的是不同问题：RSpec 给开发者验证"代码对不对"（单元/集成测试），Cucumber 给团队验证"做的是不是业务要的"（验收测试）。绝大多数团队只需要 RSpec；只有产品/业务方深度参与验收流程时，Cucumber 的 Gherkin 场景才值回维护成本。
两种语言，两类读者
RSpec 的测试是 Ruby 代码，写给开发者看：
RSpec.describe '购物车结算' do
it 'VIP 用户享受九折' do
cart = build(:cart, user: vip_user, total: 1000)
expect(cart.final_price).to eq(900)
end
end
Cucumber 的测试是 Gherkin 自然语言，写给所有干系人看：
场景: VIP 用户享受九折
假设 当前用户是 VIP
当 购物车结算金额为 1000 元
那么 实际应付金额应为 900 元
场景背后需要"步骤定义"（step definitions）把自然语言映射到 Ruby 代码执行——这是 Cucumber 的核心机制，也是它的主要成本。
维护成本的真相
Cucumber 的卖点是"非技术人员能读懂甚至编写测试"，现实却骨感：业务方很少真的写场景（写也需要培训语法规范），而开发团队要维护两层资产——场景文件 + 步骤定义库。随着场景增长，步骤冲突、正则匹配混乱、重构牵连面大等问题接踵而来。很多团队一年后发现自己维护着一个只有开发者在看的第二测试框架，这就是 Cucumber 声誉两极的原因。
RSpec 没有这层间接性：测试即代码，重构工具全程支持，失败定位精确到行。
测试层级的正确分配
- 单元/组件测试：RSpec 专属领域，快、准、细；
- 集成/系统测试：RSpec + Capybara 完全胜任（feature spec），不需要 Cucumber 也能端到端；
- 业务验收：只有当验收流程里真的坐着业务方（如金融、医疗合规场景），Cucumber 的场景才成为"活的验收文档"；否则 RSpec 的 describe 文本写到足够直白，同样能沟通。
组合使用的正确姿势
如果确实需要两者，分层原则：Cucumber 只覆盖少量核心业务旅程（注册、下单、支付这类"黄金路径"，几十条场景封顶），RSpec 承载全部细粒度测试。场景保持高层抽象（不出现字段名、按钮 ID 等实现细节），步骤定义薄而稳定——这样 UI 改版时只需调整步骤实现，业务场景文档保持不变。
常见问题（FAQ）
Q：Cucumber 和 RSpec 能跑在同一个项目里吗？
可以，互不干扰：Cucumber 场景放 features/，RSpec 测试放 spec/，CI 里分两个任务执行。步骤定义内部可以复用 RSpec 的 matcher 和 FactoryBot。
Q：有没有更轻量的"业务可读测试"替代方案？
有团队用 RSpec 的 describe/context/it 文案规范化（强制中文业务语言描述）达到类似沟通效果，零额外工具；也有团队采用 Turnip（Gherkin 语法跑在 RSpec 上）取两者折中。
Q：老项目有大量 Cucumber 场景要废弃吗？
不要一次性重写。评估每条场景：覆盖黄金路径的保留维护，重复 RSpec 已覆盖逻辑的直接删除，只在提交新场景时才执行"默认 RSpec、验收才 Cucumber"的新规。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
