RSpec中如何在结构高度相似的测试规格间共享代码

架构老林

2026-8-28

RSpec薄请求层与Service层测试去重实践方案

核心思路是先划清两层测试的职责边界砍掉无效重复，再用细粒度的复用单元替代整段式的shared examples，不要为了复用强行耦合两类测试的逻辑。

1. 先从测试职责划分层面消除无效重复

绝大多数重复的根源是两层测试的覆盖范围重叠，仅做参数转发的薄action对应的request spec，完全不需要重复覆盖Service层的所有业务分支：

Service层spec承担全量业务逻辑校验：覆盖所有成功/失败分支、返回值、数据库副作用、领域事件触发等核心逻辑
Request层spec仅承担HTTP契约校验：
- 校验参数解析、权限校验、参数格式校验这类HTTP层专属逻辑
- 校验Service返回成功/失败结果时，对应的HTTP状态码、响应结构是否符合约定
- 仅保留1个全链路不mock的集成场景验证层间参数透传正常，其余场景可以通过mock隔离Service层逻辑，不需要重复跑业务逻辑、重复校验副作用

典型场景：如果Orders::CreateService有「参数非法、库存不足、重复下单」3个失败分支，不需要在request spec里把这3个分支的数据库变更全测一遍，只需要选1个成功、1个失败场景验证HTTP返回逻辑正确即可，剩余分支全量在Service spec覆盖，直接砍掉70%以上的重复代码。

2. 用细粒度复用单元替代整段shared examples

shared examples只能抽离完整测试用例的局限性，本质是复用粒度选得太粗，不要抽整个it块，抽可自由组合的代码片段即可：

（1）带参数的shared_context解决测试数据预加载的差异

不要在shared_context里写死测试数据构造逻辑，支持传入自定义覆盖参数，适配两类spec的细微差异：

# spec/support/shared_contexts/order_creation_data.rb
RSpec.shared_context "order creation test data" do |custom = {}|
  let(:current_user) { custom[:user] || create(:user, :verified) }
  let(:target_product) { custom[:product] || create(:product, stock: 10) }
  let(:valid_params) { { product_id: target_product.id, quantity: 2 } }
  let(:invalid_params) { valid_params.merge(quantity: 0) }
end

两类spec引入时直接传参覆盖差异即可，不需要重复写FactoryBot构造逻辑：

# request spec中使用，覆盖为未认证用户场景
include_context "order creation test data", user: build(:user, :guest)
# service spec中使用，覆盖为已下架商品场景
include_context "order creation test data", product: create(:product, :offline)

（2）普通Ruby Helper抽离公共校验逻辑

把数据库副作用、返回值校验这类完全重复的expect逻辑，抽成普通的Ruby方法放在support目录，哪个spec需要就直接调用，不需要和测试用例绑定：

# spec/support/helpers/order_creation_expectations.rb
module OrderCreationExpectations
  def assert_order_created(expected_quantity = 2)
    expect(Order.count).to eq 1
    order = Order.first
    expect(order.quantity).to eq expected_quantity
    expect(target_product.reload.stock).to eq 10 - expected_quantity
    expect(order.user_id).to eq current_user.id
  end

  def assert_order_not_created
    expect(Order.count).to eq 0
    expect(target_product.reload.stock).to eq 10
  end
end

RSpec.configure { |c| c.include OrderCreationExpectations }

不管是service spec里调用完service执行方法，还是request spec里发完HTTP请求，直接调用对应的断言方法即可，完全不需要重复编写expect代码。

（3）抽离公共参数构造逻辑

把合法参数、各类非法参数的构造逻辑统一放在helper里，request spec直接把参数hash传给post/get方法，service spec直接把参数hash传给service初始化方法，消除参数构造段的重复。

3. 批量场景封装通用DSL

如果项目里存在大量「收参→调固定service→按结果返回状态码」的薄action，可以封装一层声明式的测试宏，进一步消除样板代码：

# 封装完成后，薄action的request spec只需要几行即可完成
RSpec.describe "POST /api/orders", type: :request do
  include_context "order creation test data"
  it_acts_as_thin_service_action(
    service_class: Orders::CreateService,
    success_status: 201,
    failure_status: 422,
    success_assertion: -> { assert_order_created }
  )
end

这个宏内部会自动实现：发请求、校验service是否收到正确参数、校验成功/失败对应的状态码返回，只需要传入对应的配置和专属断言即可，不需要重复写请求发送、状态码校验的样板逻辑。

避坑原则

不要过度抽象：如果某段逻辑在两类spec中的差异超过30%，直接保留重复即可，过度抽象带来的测试可维护性成本，远高于少量重复代码的成本
不要全mock service层：request spec里至少保留1个不mock的全链路集成场景，保证参数解析、透传没有问题，其余场景用mock隔离即可，兼顾测试速度和覆盖度

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

RSpec中如何在结构高度相似的测试规格间共享代码

1. 先从测试职责划分层面消除无效重复 #

2. 用细粒度复用单元替代整段shared examples #

（1）带参数的shared_context解决测试数据预加载的差异 #

（2）普通Ruby Helper抽离公共校验逻辑 #

（3）抽离公共参数构造逻辑 #

3. 批量场景封装通用DSL #

避坑原则 #